I have a NPM package (private) which works in both a browser and Node environment.
This is done by creating separate bundles via Rollup for ES and CJS, so the output looks like:
dist/ejs/index.js // Import this for your browswer environments
dist/cjs/index.js // Use this for Node environments
Pretty standard. Now I'm adding a dependency to this, which follows the same bundling pattern.
I can import the library like so:
import { externalLibrary } from "#external/ejs/externalLibrary";
All is good in a browser environment. But now this does not work in a Node environment, as what I'm importing is not CJS.
I could change the way I import the library to require and target the cjs bundle:
const { externalLibrary } = require("#external/cjs/externalLibrary");
And while this works in both environments, I don't think it's optimal.
Is there a better way of doing this? Some configuration that I could specify when exporting the CJS bundle?
module.exports = {
input: 'src/main.js',
output: {
file: 'bundle.js',
format: 'cjs'
// Behaviour here for #external/cjs/externalLibrary ?
}
};
I overlooked the package.json config. You can specify different entry files depending on the build here:
{
...
"main": "dist/cjs/index.js",
"module": "dist/ejs/index.js",
...
}
Then I removed the implicit import of the EJS file, and targeted just the package:
// Before:
import { externalLibrary } from "#external/dist/ejs/externalLibrary";
// After:
import { externalLibrary } from "#external";
This then ensures either the CJS or ES build is used, depending on the environment using the package.
Looks like you already found the solution for this, but even with old import style
import { externalLibrary } from "#external/dist/ejs/externalLibrary";
you should be able to target appropriate formats for cjs vs esm. With rollup, you would have to configure the output config to be an array of objects with appropriate format set. For example:
module.exports = {
input: 'src/main.js',
output: [{ file: 'dist/index.cjs.js', format: 'cjs' },
{ file: 'dist/index.esm.js', format: 'es' }],
}
Also, being an author of klap, I would recommend giving it a try as it would bring in lot of other optimizations by default.
Related
Using rollup is it possible to replace a specific source by another source in a NPM package during a browser bundle? Note this source is dynamically imported via import('./relativeFile.js') (I want this to be replaced).
I've specified { "browser": { "./relativeFile.js": "./browserFile.js" } } in package.json of one of the node_modules to see how it goes, but Rollup still bundles ./relativeFile.js instead. I appreciate any help.
Use the nodeResolve and replace plugins to indicate it is a browser bundle. Rollup will then replace Node sources by Web Browser sources.
import { nodeResolve } from '#rollup/plugin-node-resolve';
import replace from '#rollup/plugin-replace';
export default {
plugins: [
nodeResolve({
browser: true,
}),
replace({
values:{
'process.browser': true,
},
}),
],
};
I have a project in which I bundle a components library using Rollup (generating a bundle.esm.js file). These components are then used in another project, that generates web pages which use these components - each page is using different components.
The problem is, that the entire components library is always bundled with the different page bundles, regardless of which components I'm using, unnecessarily increasing the bundle size.
This is my Rollup setup:
import resolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';
import babel from 'rollup-plugin-babel';
import peerDepsExternal from 'rollup-plugin-peer-deps-external';
import pkg from './package.json';
const extensions = [
'.js', '.jsx', '.ts', '.tsx',
];
export default [
{
input: './src/base/index.ts',
plugins: [
peerDepsExternal(),
resolve({ extensions }),
babel({
exclude: 'node_modules/**',
extensions,
}),
commonjs(),
],
output: [
{ file: pkg.main, format: 'cjs', sourcemap: true },
{ file: pkg.module, format: 'es', sourcemap: true },
],
watch: {
clearScreen: false,
},
},
];
I have "modules" set to false in webpack, as well.
There are things you will need to do to achieve treeshakable code from both sides - the built package and the project using it.
From your code snippet, I see that you have not add flag preserveModules: true in the rollup config file to prevent the build output from bundling. Webpack can not treeshake a bundled file FYI.
export default {
...
preserveModules: true,
...
}
On the side of the project that using it, you have to specify sideEffects in the package.json - read the doc to know how to config them. Beside that, the optimization in webpack has to has sideEffects: true, also read the doc here.
Hope this helps!
As you don't know which components of your Component Library (CL) will be needed by the adopters repositories you need to export everything but in a way
the adopters can execute a tree-shaking on your CL when they do their own build (and just include what they really need).
In a few words, you have to make your CL, tree-shakable. In order to achieve this, on your CL repo you have to:
Use bundlers that support tree-shaking (rollup, webpack, etc..)
Create the build for modules of type es/esm, NOT commonJS/cjs, etc..
Ensure no transpilers/compilers (babel,tsconfig, etc..) usually used as plugins, transform your ES module syntax to another module syntax.
By the default, the behavior of the popular Babel preset #babel/preset-env may break this rule, see the documentation for more details.
// babelrc.json example that worked for me
[
"#babel/preset-env",
{
"targets": ">0.2%, not dead, not op_mini all"
}
],
In the codebase, you always have to use import/export (no require) syntax, and import specifically the things you need only.
import arrayUtils from "array-utils"; //WRONG
import { unique, implode, explode } from "array-utils"; //OK
Configure your sideEffects on the package.json.
"sideEffects": ["**/*.css"], //example 1
"sideEffects": false, //example 2
DO NOT create a single-bundle file but keep the files separated after your build process (official docs don't say this but was the only solution that worked for me)
// rollup.config.js example
const config = [
{
input: 'src/index.ts',
output: [
{
format: 'esm', // set ES modules
dir: 'lib', // indicate not create a single-file
preserveModules: true, // indicate not create a single-file
preserveModulesRoot: 'src', // optional but useful to create a more plain folder structure
sourcemap: true, //optional
},
],
... }]
Additionally, you may need to change your module entry point in order the adopters can directly access to the proper index.js file where you are exporting everthing:
// package.json example
{
...
"module": "lib/index.js", //set the entrypoint file
}
Note: Remember that tree-shaking is executed by an adopter repository that has a build process that supports tree-shaking (eg: a CRA repo) and usually tree-shaking is just executed on prod mode (npm run build), no on dev mode. So be sure to properly test if this is working or not.
Given the following code:
import { graphql } from 'graphql'
import graphqlTools from 'graphql-tools'
const { makeExecutableSchema } = graphqlTools
const typeDefs = `
type Query {
as: [A]
}
type A {
x: Int,
y: Int
}
`
const schema = makeExecutableSchema ({ typeDefs })
graphql(schema, '{ as { x, y } }').then(console.log)
I get this error:
Error: Cannot use GraphQLSchema "[object GraphQLSchema]" from another
module or realm.
Ensure that there is only one instance of "graphql" in the
node_modules directory. If different versions of "graphql" are the
dependencies of other relied on modules, use "resolutions" to ensure
only one version is installed.
What's going on?
This situation may also occur when the version of the graphql module you have installed is different from the version installed and used by graphql-tools.
I have found you can correct this by either:
Changing the version of graphql in your project's package.json file to match exactly what graphql-tools depends on in its package.json file.
Removing graphql as a dependency and just installing graphql-tools. Then you will automatically receive whatever graphql module version that graphql-tools installs (as long as you don't depend on any other packages that install another, conflicting version).
In other cases you might have the correct version, but it may be installed multiple times. You can use npm ls graphql to see all the installed versions. Try running npm dedupe to remove duplicate installations.
This happens because graphql-tools module imports graphql from its CommonJS module, while my code does it from the ES module. That is, each object in my own module comes from the ES module, while graph-tool's not.
Solution
It's as easy as importing anything from graphql importing the CommonJS module, and both objects from graphql and graphql-tools will be able to talk each together:
import graphql_ from 'graphql/index.js'
import graphqlTools from 'graphql-tools'
const { graphql } = graphql_
const { makeExecutableSchema } = graphqlTools
const typeDefs = `
type Query {
as: [A]
}
type A {
x: Int,
y: Int
}
`
const schema = makeExecutableSchema ({ typeDefs })
graphql(schema, '{ as { x, y } }').then(console.log)
My problem was both .js an .mjs graphql files are resolved due to wrong webpack configuration.
Root cause:
From TypeMapper.mjs file in graphql-compose, import statement does not have file extension and that was a failure on webpack bundle. In order to solve it, I required to add fullySpecified:false into the webpack config.
{
test: /\.m?js/,
include: /node_modules/,
type: "javascript/auto",
resolve: {
fullySpecified: false
}
}
And I also modified resolve statement like
resolve: {
extensions: [".ts", ".js", ".mjs"] // that was the actual problem
}
Since fullySpecified config has been set to false, webpack was trying to resolve files without extension respect to the order of resolve.extentions config. Due to the wrong order in that config, graphql files with .js ext were been resolving although all other files were using .mjs one.
Solution:
Simply re-order resolve.extensions config as
resolve: {
extensions: [".ts", ".mjs", ".js"]
}
In my case, I added the webpack-node-externals library to the webpack configuration, and I was able to run my bundled application.
externalsPresets: { node: true },
externals: [nodeExternals()],
I am using webpack version 5.*
Also I am using yarn package manager, so I added resolutions in my package.json
"resolutions": {
"graphql": "^15.3.0"
}
For me, it was solved by downgrading some packages like this:
"apollo": "^2.33.4", "graphql": "^15.5.0",
I also deleted node_modules and package-lock.json and installed packages with yarn instead of npm.
I got this exact error when my .npmrc did not have proper entries such as username and password. We are using jFrog to normalise package installation. .npmrc should be located at root with proper entries.
ex: .npmrc file which works
#<company-name>:registry=<registry-url>
//<artifactory-name>:_password=${PASSWORD}
//<artifactory-name>:username=${JFROG_USERNAME}
//<artifactory-name>:email=${YOUR_EMAIL}
//<artifactory-name>:always-auth=true
Will webpack produce different results given a configuration like so:
// webpack.config.js
module.exports = {
...
entry: {
main: ['./index.js'],
}
}
// index.js
import 'babel-polyfill'
...
vs.
// webpack.config.js
module.exports = {
...
entry: {
main: ['babel-polyfill', './index.js'],
}
}
// index.js
// babel-polyfill import removed
...
Which one is preferred, and why?
Both works kind of the same way.
The option 1, webpack would treat babel-polyfill as a dependency, in the dependency tree.
The second one, webpack would treat babel-polyfill as an entrypoint, where it would try to generate a dependency graph from that, which would have 0 dependencies.
There is no real difference here, nor any impact on the result bundle, both will contain babel-polyfill anyways, and also there is no "preferred" way to add that, babel itself refeers to both ways on their guide.
The result will be the same. It depends on you, usually I prefer to import the dependencies in modules rather than importing implicitly in webpack config.
I've installed three.js library through NPM to get advantage of the new ES6 modular architecture which should let you to import just the modules you need, as explained here: Threejs - Import via modules.
I am using gulp, browserify and babel for bundling and transpiling, like so:
gulp.task("build_js", () => {
return browserify({
entries: "./public/app/app.js",
cache: {},
dev: true
})
.transform(babelify, {presets: ["env"], plugins: ["syntax-async-functions", "transform-async-to-generator"], sourceMaps: true})
.bundle()
.pipe(source("app.bundle.min.js"))
.pipe(buffer())
.pipe(sourcemaps.init({loadMaps: mode}))
.pipe(uglify())
.pipe(sourcemaps.write("./"))
.pipe(gulp.dest(config.build.js))
});
I want to import only the modules I need and keep the bundle size small, but I noticed that the bundle generated by browserify has the same size regardless if I import all the modules or just one.
If in app.js I import all the modules I got a bundle size of about 500Kb:
// app.js
import * as THREE from 'three'; // about 500 Kb size
But if I try to import just a specific module using ES6 syntax I got the same bundle size (it is importing again all the modules):
// app.js
import { Vector3 } from 'three'; // about 500 Kb size, same as before example
I've also tried the following:
// app.js
import { Vector3 } from "three/build/three.module.js";
But I got the following error:
SyntaxError: 'import' and 'export' may only appear at the top level (45590:0) while parsing /Users/revy/proj001/node_modules/three/build/three.module.js
My question: how can I properly import only the modules I need and keep the bundle size small?
You are missing the concept of Tree Shaking.
When you import a modules by name the other modules are not automatically removed from the bundle. The bundler always includes every module in the code and ignores what you have specified as import names.
The other unused modules, which you did not import, are considered dead code because they are in the bundle however they are not called by your code.
So to remove this unused code from the bundle and thus make the bundle smaller you need a minifier that supports dead code removal.
Check out this popular tree shaking plugin for browserify - it should get you started:
https://github.com/browserify/common-shakeify
Solved using rollupify inside browserify transform. It will perform tree shaking and remove dead code:
gulp.task("build_js", () => {
return browserify({
entries: "./public/app/app.js",
cache: {},
dev: true
})
.transform(rollupify, {config: {}}) // <---
.transform(babelify, {presets: ["env"], plugins: ["syntax-async-functions", "transform-async-to-generator"], sourceMaps: true})
.bundle()
.pipe(source("app.bundle.min.js"))
.pipe(buffer())
.pipe(sourcemaps.init({loadMaps: mode}))
.pipe(uglify())
.pipe(sourcemaps.write("./"))
.pipe(gulp.dest(config.build.js))
});
}
Still I would appreciated an explanation on why ES6 module import works like this..