In my project I need to use the npm module ipfs-api with create-react-app.
I can run npm start and run the proect.
But when I try to build the proect with react-scripts build, it throws the following error
Failed to compile.
Failed to minify the code from this file:
./node_modules/ipfs-api/src/utils/module-config.js:7
Read more here: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#npm-run-build-fails-to-minify
According to the suggestions in the provided link in eorror log, I tried using,
"dependencies": {
...
"ipfs-api": "github:atfornes/js-ipfs-api#transpiled",
...
}
instead of "ipfs-api": "^22.0.0",. Although this solved error for ipfs-api, other dependent modules (probably installed with ipfsapi) kept giving same type of Failed to minify errors which I stopped transpiling them manually.
Is there a way to transile all the dependent node modules to es5 while before using the command react-scripts build ? Or any other way to overcome this issue?
Usually client-side or platform independent packages are compiled to ES5 on publishing. That you have this problem may suggest that the package isn't intended for client side.
As the documentation explains, the package contains a bundle for browsers that includes polyfilled Node features (streams, etc.) that are needed to run it on client side.
It's supposed to be used as a global:
import 'ipfs-api/dist';
ipfs(...)
Is there a way to transile all the dependent node modules to es5 while before using the command react-scripts build ?
This would require to eject create-react-app configuration and configure Webpack to transpile this package properly. This example from the documentation shows how Node-specific parts should be configured to bundled for browsers.
Related
I have a frontend project in React and another in Vue where other developers will be making pushes to the repo. I am using a set version of node and npm but what is the best way to enforce these versions for other developers so that the js bundles they build will be using the same? We currently don't have a proper build process so the build of the bundles are just done through the command line (e.g. npm build production).
You can use a engines property in package.json and can use "engineStrict": true in order to enforce it.
{
"engineStrict": true,
"engines": {
"node" : ">=0.10.3 <0.12",
"npm" : "~1.0.20"
}
go one directory up and then install it like - npm install myproject that will trigger the checks for engines and engineStrict.
If the particular versions are not present then it will throw error.
However engineStrict was removed in npm 3.0.0 so you can use npm --engine-strict=true from command line.
For me, Webpack is a bundler for "web" since browsers don't have good support for js module system. Thus using Webpack we could still use "module" way to develop and pack them for browsers.
Webpack has a config option target
module.exports = {
target: 'node'
};
using node webpack will compile for usage in a Node.js-like environment
But NodeJS already support CommonJS modules, why need Webpack to build something that runs in NodeJS environment?
Besides, if you want to compile your javascript, for example, using the ES module, you could just use babel to do so, using es module transform plugins or proper presets.
Why use Webpack, set the target to node and then use babel loader... instead of using babel directly?
I cannot think of the use case of using Webpack to bundle application running in node.
One reason I can think of when to use webpack for node is when you have a node_modules package where it's not compiled yet (Still in ES6).
babel-node won't be able to help you bundle the node_modules packages that need to be transpiled along with the rest of your code
I had to go through this process.. ): This scenario is helpful in Yarn Workspaces where you want your server to depend on another package in your workspace. Where your server will re-update whenever you make changes in the other package with the help of webpack
How to include a few node_modules package in babel-node
Having a single server.js output
instant deployable on a server
no worry about mismatching dependencies compared to your dev environment.
I have a common npm module containing TypeScript which is an node module providing some classes and functionality. This module is packaged via browserify + tsify and also exports the declaration files and built with gulp.
I have another npm module using TypeScript which imports this module locally via file:../modulename and tries to use functionality from the first module. The second module is also packaged via browserify + tsify and built with gulp. The compilation of the second module works via npx tsc, but fails if I execute the gulp build file with the error message
Error: Cannot find module './AbstractClass' from 'folderInOtherModuleContainingTheJSFiles'
Interestingly it sometimes fails with this Class sometimes with another, so it seems there is also some kind of concurrent processing.
I extracted the failing code from my project and created a minimal example with this behavior here.
npm version: 5.6.0
node version: v9.5.0
For anybody who might come to this post and face the same error.
I opened an issue at tsify too, thinking it has something to do with the plugin, because npx tsc worked.
Luckily the issue has been resolved, although with a workaround. There seems to be a name collision which causes browserify to think that a require call, which is a variable, in the resulting bundle needs to be resolved, but can't. The workaround is uglifying the resulting bundle, so that the conflict does not happen. More details in the above linked issue.
Should the repository for a library written in Typescript contain a JS version for the consumer? Or should I leave it to the consumer to compile it themselves? Or neither?
As a general rule, I only include the source files in the repo. There is a reasonable expectation that a person downloading the source will want to work with the source and build it. Meanwhile you can offer build tools/commands to help them build it. For npm modules, your package.json might have a postinstall script that runs the tsc command. As long as TypeScript is a dependency, npm will download the necessary libraries and execute the TypeScript build when the user does an npm install on the repo once cloned locally.
I have created a npm module with es6. You can see it on github here.
There are some scripts in the package.json file which should ensure that the es6 modules get built. It works when running npm publish and npm install when in the context (directory) of the npm module. Running npm install in another project (ie including the module as a dependency) does not however build the es6 modules. There don't seem to be any errors in the npm-debug.log file either.
I'd really like to understand why.
It was caused by the lack of a .npmignore file. As there wasn't one, npm was using the .gitignore file instead. This filters out the dist/ folder which I don't want in source control. This commit fixed the issue
Your script is missing an install (or postinstall) script.
If you are building the code with a script on the prepublish hook, then you don't need it to be built again when others install it. It should ship with the built ES6 code.
In fact, you probably want to add your src directory to your .npmignore file, so that it doesn't ship with any JS that can't be used directly.