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 :)
Related
I'm trying to make a simple Yeoman generator in ES6.
I think I followed the documentation.
After $npm linkin the current folder of my generator i go in another directory and try :
? 'Allo Emmanuel! What would you like to do? (Use arrow keys)
Run a generator
❯ Starterpack
──────────────
Update your generators
Install a generator
Find some help
Get me out of here!
──────────────
My Generator seem to be avaible, but not :
Make sure you are in the directory you want to scaffold into.
This generator can also be run with: yo starterpack
Error
You don’t seem to have a generator with the name “starterpack:app” installed.
If needed all code are available here : https://github.com/ethyde/generator-starterpack
What I did wrong ?
Thanks.
EDIT : Fixed, thanks, I have updated the repo with the answer.
Your generator is not exporting a standard node module. See this line https://github.com/ethyde/generator-starterpack/blob/master/generators/app/index.js#L77
Babel by default compile es6 module files to exports.defaults. Yeoman expects a usual Node.js export. In other words, it expects your generator to be exported as module.exports = Generator.
You'll need to update your babel configuration.
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.
we started our project with ES6 javascript skeleton.
we would like to extract some styles and custom attributes to a common folder so we can use these at any Aurelia module we will build in the future.
the problem is with the bundle files. we don't know how to config them to bundle external folder out of the main ES6 folder.
can you please tell us what to do?
It sounds like you want to build an Aurelia plugin that you can import into any project. I would start by taking a look at the Aurelia plugin skeleton.
Once you've built your plugin with the custom styles and attributes you want, you'll want to either register it with jspm as a link, or publically through a registry such as npm or github.
Once published, you will be able to jspm install registry:my-package in any new project, and add the following line to your main.js file:
export function configure(aurelia) {
aurelia.use
.standardConfiguration()
.plugin('my-package');
}
For more information on this last step, see the brilliant answer provided by Ashley Grant here.
It seems that you have to manually checkout a bunch of repos, and when I tried to run the core-tests runner.html, they reference htmls from outside the folder which is restricted by the browser
Polymer uses a notion of components. We define a component as a set of shareable resources in a folder. All of your components should be together in one master folder (I usually call it components). This way one component can reference another component by looking in ../<component-name>/.
A project will generally look something like this:
my-project/
index.html
components/ <-- could be symlink or a server redirection
platform/ <-- polyfills
polymer/ <-- polymer
core-ajax/ <-- a custom element
...
core-tests in particular, is itself a component. It lives in the components folder and runs tests on other components (by looking at ../<component-name>/ as above).
So, if your web-root in the example above is my-project, you should be able to access my-project/components/core-tests/runner.html to run those component tests.
There are multiple ways to populate the components folder. The easiest way is to use Bower (http://bower.io) with a command like bower install Polymer/core-elements.
You can also use Git checkouts, or ZIP archives. There is a nifty utility for downloading Bower packages as zip files at bowerarchiver.appspot.com. E.g.:
http://bowerarchiver.appspot.com/archive?core-elements=Polymer/core-elements
Will get you a zip of the core-elements Polymer component, with all of it's dependencies.
There are two Yeoman generators that can help you with starting off: yo polymer and yo element
yo polymer is based on the polymer seed-element and yo element is based on the polymer-boilerplate.
I ended up writing a blog post on getting the hang of these different setups. If you get the latest version of the generator from the github repo it will scaffold an app for you:
npm install -g git+https://github.com/yeoman/generator-polymer.git
Also make sure to have a look at the vulcanize task to concat your components.
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