npm start error – TypeError: Path must be a string. Received undefined

This is a common generic error received whilst attempting to run older typescript based projects still using the now deprecated TSD package manager, on a system using TSD’s replacement Typings.

tl;dr  I just want to get this thing running quickly:
Installing (the deprecated) TSD package manager is often fastest way to get around these backward compatability issues:

$ npm install tsd -g

[disclaimer]using deprecated software is bad, see below for real fixes![/disclaimer]

 

Ok, now let’s look at actually fixing the problem.Unfortunately, the error’s output can be rather ambiguous, generic and difficult to get much helpful info from:

$ npm start

> node start.js
ts-loader: Using typescript@1.8
webpack built [...hash] in 1ms

ERROR in ./src/index.tsx
Module build failed: TypeError: Path must be a string. Received undefined
at assertPath (path.js:7:11)
at Object.dirname (path.js:1324:5)
at ensureTypeScriptInstance (/[...project src dir]/index.js:156:103)
at Object.loader (/[...project src dir]/node_modules/ts-loader/index.js:375:14)
@ multi main

 

Suspecting the error may be due to the project having been created using TSD rather than Typings, with the project having a tsd.json file rather than a typings.json file.

TSD has now been deprecated in favor of Typings, but the quickest way to get the project running is to install TSD, however this is obviously not ideal for anything but quickly checking out a project.

The Typings website provides info on how to upgrade from TSD to Typings, here:
https://github.com/typings/typings/blob/master/docs/tsd.md#upgrade

The official deprecation notice on the TSD GitHub page provides some more useful info and background too:
https://github.com/DefinitelyTyped/tsd/issues/269

A potential confusion is that the tsconfig.json remains the same name (although some parameters may need altering, moved file references updated/deleted), now the tsd.json is called typings.json with a similar config, but potentially also in need of manual editing after running the basic Typing’s upgrade process.

But hopefully, running npm start should work:

$ npm start
Compiled successfully!

The app is running at:

 http://localhost:3000/

 

If this does not work, a couple of additional steps may be required, including (but not limited to):

  • If a webpack compile errors say “Module build failed: Error: ENOENT: no such file or directory,” you should check your tsconfig.json file is not referencing any old tsd files which no longer exist (usually in the project’s typings/ directory).
  • You may need to create a tsconfig.json file in your project root directory (i.e. usually same one as package.json etc) if you do not already have one, visit the Typescript language homepage for more info. (Courtesy of https://www.garysieling.com/blog/fixing-webpack-error-path-must-string-received-undefined)
  • You may need to upgrade one or more old npm dependencies in your package.json file. Tools like npm-check-upgrades can help (use npm-check-upgrades -u to actually install the newer package versions – warning: may break the application).
  • Try suggestions from the above links, (e.g. the TSD deprecation announcement).
  • If all else fails, undo everything so far (if a git repo type:
    $ git checkout — .
    ) and install the TSD package manager (deprecated and bad, but a potential short-term workaround):
    $ npm install tsd -g

 

These package upgrade errors do seem to happen with a regular frequency, but are usually solvable with a bit of work. If the above solutions did not work for you or you have succeeded using another, please let others know about it in the coments.

Advertisements

Programming Cheat Sheets

Great collection of programming language cheat sheets listed in this article.

Nice just to browse them all for fun.

As a follow-up question, what opinions do people have on cheat sheets in aid of teaching or learning new skills? I’ve always found them a great tool but many other teachers proclaim that they’re flawed.

Comments & opinions welcome.

Node-inspector console not working in latest version of Google Chrome

The latest version of Google Chrome doesn’t execute commands when the Enter button is pressed and instead just wraps to a new line. Instead of downgrading Chrome, a quick fix appears on the node-inspector issue list here.

Quick Fix

Edit node-inspector’s config file (below is global npm installation path, local in project’s node_modules directory):

$ nano /usr/local/lib/node_modules/node-inspector/front-end/platform/DOMExtension.js

Search for the isEnterKey function (line 779) and comment out the line:
return event.keyCode !== 229 && event.keyIdentifier === "Enter";
Replacing it with:
return (event.keyCode !== 229 && event.keyIdentifier === "Enter") || event.keyCode === 13;

So the function now looks like:

function isEnterKey(event) {
    return (event.keyCode !== 229 && event.keyIdentifier === "Enter") || event.keyCode === 13;

    // Check if in IME.
    // return event.keyCode !== 229 && event.keyIdentifier === "Enter";
}

Save, restart node-inspector and your node process manager (e.g. nodemon, pm2 etc) and node-inspector once again executes console commands via the Enter key.

Changing the default keyboard shortcut of a Chrome Extension

Changing the keyboard shortcuts of some Chrome web browser extensions can be a pain when the preferences option is non-editable in chrome://settings. A some-what longwinded workaround is to edit the source code of the extension directly. Often this is available on somewhere like GitHub.

To change a Chrome extension keyboard shortcut via its source code, the steps are as follows:

  1. Clone the extension source code to your computer
  2. Open the manifest.json file in the extension’s route directory. Edit or add this section:”omnibox”: { “keyword” : “key” }

Where “key” is the keyboard shortcut key itself. As an fyi, Chrome likes to calls its address bar the “omnibox”

  1. In chrome, go to: chrome://extensions/
  2. Delete the old extension (careful of deleting important data if relevant)
  3. Switch on developer mode in top right of page
  4. Select Load unpacked extension... and navigate to the cloned directory
  5. Verify the extension has loaded in Chrome and works correctly
  6. It is a security risk to browse the Internet with Chrome Extensions developer mode left on. Solve this by packing the extension into a single .crx file (a type of .zip file).
  7. Delete the newly created “unpacked” extension and click Pack extension... (you can sign the file with a .pem key but this is not necessary).
  8. Switch off developer mode in top right of page
  9. Nagivate to the directory above the cloned directory
  10. Drag the .crx file produced in the packing step onto the Chrome window
  11. The new extension should now appear on the chrome://extensions/ page
  12. Verify the correct result by navigating to chrome://settings/ -> Manage search engines...
  13. At bottom of page under “Search engines added by extensions” the keyboard shortcut should be updated and extension only appears once

 

You now have a modified keyboard shortcut for a Google Chrome extension. Some installations may experience problems with the browser disabling the extension unless it is officially released through the store (private repos are available). If the extension is disable then a restart of the web browser usually suffices in making the extension work again.

Abstracting logic with AngularJS controller inheritance

As with most frameworks, it’s a good practice in AngularJS apps to abstract common elements out of your application’s different controllers. Whilst injecting custom Services often represent a good way to achieve this, another complimentary approach is to make use of AngularJS’s controller inheritance. As an example, consider the following AngularJS controllers:

And the following html:

This will give the following output:

Menu1 value
Menu2 value
Default Value

This technique can be combined with injected services to allow complex data structures and common initialisation logic to be abstracted to parent controllers and then overridden where desired.

In Javascript, the “equal and of the same type” definition only applies to values

The colloquial definition of === is “equal and of the same type” however this is only true for values. For objects, both x == y and x === y comparison will return false even if the x & y objects are identical in every way, it will only return true if x & y are both references to the same object. In the case of == this can be overridden with the use of a toString() / valueOf() functions, but not ===.

The actual definition of equality operators is that == tests for “loose equality” and === tests for “strict equality”. This rather ambiguous definition gives opening to the strange and somewhat inconsistent results which can arise during intricate equality comparisons.

The Mozilla Developer Network has a good rundown on how this loose comparison works out.