A year or so ago I wrote a Javascript library that I then ported (badly) to Typescript and which was adding the sweet versatility and performance of LINQ to the *script world. Now I've rewritten the entire thing into a Typescript library. I've abandoned the separation into three different Javascript files. It is just one having everything you need.

I haven't tested it in the wild, but you can get the new version here:

Github: https://github.com/Siderite/LInQer-ts

NPM: https://www.npmjs.com/package/@siderite/linqer-ts

Documentation online: https://siderite.github.io/LInQer-ts

Using the library in the browser directly: https://siderite.github.io/LInQer-ts/lib/LInQer.js and https://siderite.github.io/LInQer-ts/lib/LInQer.min.js

Please give me all the feedback you can! I would really love to hear from people who use this in:

• Typescript
• Node.js
• browser web sites

The main blog post URL for the project is still https://siderite.dev/blog/linq-in-javascript-linqer as the official URL for both libraries.

Have fun using it!

Update: the initial article was plaing wrong :) I fixed it now. The important change is that you need to npm link the dist folder, not the root folder of the plugin project.

So, the question arises when you want to change a module that is used (and tested) in another module. Let's say your normal flow is to change the version of the child package, then npm run packagr, then npm publish it, then npm install childModule@latest in the parent app. This quickly gets tiresome and leads to unrealistic version numbers.

A better solution is to use npm link. First, you go to your plugin/child module and you run npm run packagr. When it's done, go to the dist folder and run npm link. This will create a symlink in the global node_modules folder for your project's distribution package. Then, move to the parent module and run npm link <name-of-child>. The name of the child is the same as the name of the application. This creates a symlink in the parent module's node_modules to the global symlink created earlier.

Wait! A few gotchas, first:

• careful with the operations that might change the content of the folder linked in node_modules, as they will change the actual source code of the plugin
• after you finish with the work on the plugin, then delete the symlink, publish the child and reinstall @latest at the parent
• make sure that the version of the plugin package in the parent is permissive (something like >=initialVersion), otherwise you might have problems with the version number you set in the plugin package.json file

Hope this helps.

NPM is a popular package manager (think NuGet for JavaScript) and the information of the packages that it needs to install is stored in a file called package.json. You run npm install, packages are getting downloaded in a folder called node_modules and a package-lock.json file is generated. Since you can always delete node_modules and package-lock.json and rerun the package install, a common assumption is that they are redundant and they shouldn't be stored in source control. That is wrong in most cases.

The lock file not only stores the progress of the npm installation, but also the actual versions of the packages that it installs (for the entire dependency tree). As opposed to this, package.json contains only the packages directly needed by the project and the acceptable ranges of the versions. One can allow for any version of a package to be used, or maybe anything above a version, or an interval or something that is "the best version" around a specific version. Deleting the package-lock.json file effectively tells NPM that you trust package.json and the developers of each package for the versions of the dependencies loaded.

Here is a common scenario: you create a new application, you need some NPM packages so you npm install thePackage. This gets the latest version of thePackage and installs it, then marks the exact version into package-lock.json as well as the versions of the packages thePackage uses and what they use and so on. Finally, you commit the project, including package-lock.json. Three months later, a new developer comes and gets the project from source control. They use npm install and see that everything works perfectly, because the packages restored are the exact same versions as the ones restored for the original developer. But now they think "who committed package-lock.json? Don't they know it's redundant?" so they remove it from source control. Three months later another developer comes and runs npm install on the source from the code repository, only nothing works anymore. The versions that were downloaded are, depending on what is specified in package.json, the latest version of the dependency or maybe a version similar, but with a different minor version, and with the dependencies that the developers thought best for that particular version.

There is a situation when package-lock.json is entirely redundant and that is when package.json only specifies exact versions. NPM works so that you cannot replace the same version of a software in their repository, so the devs will never be able to change the package versions they used for a specific version. That is why it is safe to assume that the same version of a package will use the same package dependency tree (unless some of the packages are removed, but that's another question entirely).

Summary: If you have any version of a dependency in package.json specified as anything else than a specific version (no tilde, no caret, no asterisks, no intervals), then you also need to store package-lock.json in your source control.