How do I import Immutable.js as an es6 module? - immutable.js

I'd like to use immutable.js in an es6 project using import. My bet is I'm missing the obvious, but:
Is there an es6 module format? (couldn't find it in npm install nor github)
If so, where? I tried the unpkg.com trick with ?module and no luck
If not, how do I make my own.

Turns out it is in a RC release:
https://github.com/facebook/immutable-js/releases/tag/v4.0.0-rc.3
Available as: https://unpkg.com/immutable#4.0.0-rc.9/dist/immutable.es.js
You can also use unpkg's ?module feature: https://unpkg.com/immutable#4.0.0-rc.9?module

Related

PhpStorm can't resolve package import even though it exists (react-router-dom)

I am using React (16.12.0) with PhpStorm (2019.3.1).
The package I am importing is react-router-dom (5.1.2)
I will write the following import:
import { NavLink, Switch } from "react-router-dom";
Both packages are imported properly by webpack/babel and the page renders properly when I use both Switch and NavLink.
However purely from the IDE-perspective, I get a warning about Switch: Cannot resolve symbol 'Switch'
It is weird because it is obviously there, and I checked in /node_modules/react-router-dom and Switch.js is there.
Strangely on previous versions of PhpStorm (before several updates and plugin imports and other changes), the Switch import was accurately found by PhpStorm.
I have not updated react-router-dom recently and am using its latest stable build.
Any ideas as to why it might be missing Switch?
EDIT:
I have realized it may be because PhpStorm is having difficulty importing a commonJS module.
I tried changing the Javascript compilation method from React JSX to ECMA 6. That didn't work.
I also tried importing some build libraries for react-router-dom, and that worked for recognizing the Route import strangely but not Switch.
I also tried invalidating the PhpStorm cache and restarting the app, but that didn't work either.
EDIT 2:
Per an answer, I have tried to use option+enter (alt+enter on windows) while my cursor is within react-router-dom to try to install a typescript package, but I don't get the same suggested action as shown on the JetBrains website: https://www.jetbrains.com/help/webstorm/configuring-javascript-libraries.html
All it suggests is switching single quotes to double quotes.
Also I have already installed #types/react-router-dom. Perhaps there is another one that I am missing?
EDIT 3:
The correct answer was to install #types/react-router. For some reason #types/react-router-dom is deceivingly NOT what solves this.
node_modules/react-router-dom/esm/react-router-dom.js exports BrowserRouter, HashRouter, Link and NavLink, but doesn't export Switch, it's not explicitly defined there.
For better completion/type hinting, you can install Typescript stubs for the package: put cursor on "react-router-dom" in import statement, hit Alt+Enter, choose Install TypeScript definitions for better type information::
See https://www.jetbrains.com/help/webstorm/2019.3/configuring-javascript-libraries.html#ws_jsconfigure_libraries_ts_definition_files

How to determine ES version of a module

The Testing React Native Apps section of jest docs says,
The transformIgnorePatterns option can be used to whitelist or blacklist files from being transformed with Babel. Many react-native npm modules unfortunately don't pre-compile their source code before publishing.
Lets say I add a new npm module(say X) to my project.
Now, I would now like to know if this(X) module is precompiled to maybe ES5 version, or is it still exported as a es6/es7/typescript module.
This will help me to figure out if I need to whitelist/blacklist the(X) module from being transformed.
Is there a way to find out the ES version of a exported module?
I think, this NPM package is exactly what you need :)

How do I check what ES version will be required by a browser?

I have a JS application that is bundled using webpack. It is mostly VueJs, with some jQuery and raw JS. It calls in a number of libraries and uses some ES6 features.
I think webpack is transpiling down to ES5, but I am not 100% sure. I would like to be able to check the output JS, to find out if it is definitely ES5 or lower. How can I do that?
I tried this node module, https://www.npmjs.com/package/es-check, but could not get any sense out of it. It keeps saying that it can't find any files to check.
A simple solution could be to use grep or similar on the bundle and search for any of these:
cat bundle.js | grep =\>
arrow function =\>
declarations let\ const\

Loading multi versioned Web Component dependencies with SystemJS / JSPM?

Just a disclaimer - this is a hypothetical scenario as I'm trying to figure out the best way to handle web component direct and transitive dependencies using something like JSPM and SystemJS.
Scenario 1
Suppose I have 2 web components - component-a and component-b. One is built with momentjs#1.2.4 and another is built with momentjs#1.6.4.
Each component author listed Polymer as a peer dependency and momentjs as a direct dependency in their package.json file like this:
"dependencies": {
"moment.js": ">= 1.0.1 <= 1.8.0"
}
"peerDependencies": {
"Polymer.js": "0.5.0^",
}
So in this case when the developer declares the package.json dependencies on both of these components the package manager could figure out the best version of moment.js to install and make it available. Lets assume that's version 1.8.0.
Great - just one version of moment.js to deal with for both components. Now how do the components load / inject the dependency? Does JSPM and SystemJS currently have the ability to support this?
For example in this article Taming Polymer with SystemJS and Typescript the author performs imports that delegate to SystemJS like this:
import 'elements/app-frontend';
So I suppose momentjs would follow a similar approach and import like this (Within the typescript files of component-a and component-b:
import 'js/momentjs';
In the above case the momentjs dependency does not know what version will be fetched since the import declaration is unaware of the version (since it written at design time).
Later on when the component is used in and component is used in an application JSPM figures out the best for the momentjs depedency to install.
In this case lets assume that it install it in a layout like this:
`jspm_packages/momentjs/momentjs#1.8.0`
So how does JSPM become aware the import statement import 'js/momentjs' translates to the import of jspm_packages/momentjs/momentjs#1.8.0?
In this case it's fairly trivial, but it get more tricky in scenario 2 below ... I think.
Scenario 2
Same as scenario one except the version requirements on momentjs are mutually exclusive. For example component-a requires version 1.2.4 and component-b requires version 2.4.4.
So both components perform the import like this:
import 'js/momentjs';
But jspm_packages installs both versions like this:
`jspm_packages/momentjs/momentjs#1.4.4`
`jspm_packages/momentjs/momentjs#2.4.4`
So now how does SystemJS know to that component-a needs version 1.4.4 and component-b needs version 2.4.4?
To summarize:
1) Is JSPM ok with having multiple versions of the same dependency?
According to this article Introduction to the Jspm package manager and the SystemJs module loader and an answer from guybeford it does, but how then does each component get the right version?
2) Does SystemJS / JSPM have a way of configuring version meta data for each component?
3) Does SystemJS have a way of understanding and injecting the right version of a dependency into the web component?
TIA,
Ole
Also what happens if the component requires several other modules, like CSS etc?
I'm not sure what you mean. You can import multiple modules and other contents (likely via plugins) usting SystemJS.
1) Is JSPM ok with having multiple versions of the same dependency?
I think you partially answered this question. JSPM will always select and install only one version for each component, which best matches the requirements from other components. If there is a conflict, JSPM will ask to choose manually.
So how does JSPM become aware the import statement import 'js/momentjs' translates to the import of jspm_packages/momentjs/momentjs#1.8.0?
The config.js file assigns import names (not sure the nomenclature) for installed packages. It is actually possible to change those names using jspm install x=npm:package syntax. This will result in config like
"x": "npm:package#1.2.3"
You can then both import x and import npm:package#1.2.3.
2) Does SystemJS / JSPM have a way of configuring version meta data for each component?
I think that the structure of config.js has all you need. It contains dependencies with their versions.
"component-a": {
"momentjs": "momentjs#1.2.4"
},
"component-b": {
"momentjs": "momentjs#1.6.4"
}
3) Does SystemJS have a way of understanding and injecting the right version of a dependency into the web component?
I would expect SystemJS to use this information to import the correct version when either component-a or component-b is requested.
I am not sure though how to have JSPM install packages this way, retaining multiple versions of a package. I think it deserves a separate, specialized question.

Can't include JSON::XS module locally in CGI perl script but can include JSON module

So for a particular CGI perl script I have included JSON like this to handle some .json files:
use lib "./modules/JSON/lib";
use JSON;
This works fine and well. The web directory holds the files required in the modules folder.
However, the JSON module is very slow. I read that JSON:XS can be much, much faster but I can't seem to simply use it as so:
use lib "./modules/JSON-XS";
use JSON::XS;
There is no lib folder in the JSON-XS files, i've tried combinations of use (ie, using both folders and etc) but it didn't work.
And no I cannot simply install the module for this particular project.
Any help is appreciated.
And no I cannot simply install the module for this particular project.
You can't use a module without installing it. You've just been getting away with doing a half-assed job of it. That won't work for JSON::XS, though. The reason it's fast is because it's written in C, so you'll need to compile the C code. The easiest way by far to do this is to use the provided installer instead of reinventing the wheel.
(You do know you can install a module into any directory, and that this does not require special permissions, right?)
Perl distributions are usually usable in an uninstalled state. What you just need to do is to call perl Makefile.PL && make (or for a Module::Build-based distribution: perl Build.PL && ./Build). This will do all necessary compilations (if it's an XS module) and copy the library files into the blib subdirectory. In your script instead of use lib you would write use blib:
use blib "/path/to/JSON-XS";
Note that if a module has dependencies, then you have to resolve it yourself and add that many use blib statements. JSON::XS does not have that many dependencies, but it will be really inconvenient for other modules. In this case you should probably seek another solution, e.g. using CPAN.pm together with local::lib.
Okay this finally worked for me:
I did this process to all the dependencies (in the order of no dependencies to more dependencies)
export PERL5LIB = ~/path/to/modules/perl5
perl Makefile.PL PREFIX=$PERL5LIB LIB=$PERL5LIB
make
make test
make install
This installed all modules into a directory I called perl5. It also means that when you try to install other modules locally the dependencies issue does not appear due to the PREFIX/LIB additions.
Then all I did was add this to my perl CGI script:
use lib "./modules/perl5";
use JSON::XS;
PS: JSON::XS is so much faster!
:D