Use Rollup for bundling dependencies

[tommy-mitchell]

Closes #67. Bumps dev dependencies and adds an _actualDependencies field.

Builds on prepare and outputs a bundled dependencies.js and licenses.md to the build folder:

\__ build/
	\__ licenses.md # License of each bundled dependency
	\__ dependencies.js # Vendor bundle
	\__ index.js
	\__ options.js
	\__ parser.js
	\__ utils.js
	\__ validate.js
\__ index.d.ts
\__ license
\__ package.json
\__ readme.md

[sindresorhus]

I don't want to minify the code. Debugging is important. It also doesn't save much anyway.

[sindresorhus]

How should dependencies in package.json be specified?

They need to be devDependencies, but it would be nice to somehow indicate which are used in production. We could maybe create a custom field like in package.json: {"_actualDependencies": ["..."]}.

[tommy-mitchell]

They need to be devDependencies, but it would be nice to somehow indicate which are used in production. We could maybe create a custom field like in package.json: {"_actualDependencies": ["..."]}.

Would bundleDependencies work?

[sindresorhus]

Would bundleDependencies work?

I don't think so. It would bundle the dependencies. So we would still have double up of the code (both rolled-up and npm bundled).

[tommy-mitchell]

Fair enough. I'll add a custom field. If we're not minimizing, maybe we should only bundle the dependencies?

\__ dependencies/
    \__ licenses.md
    \__ bundle.js
\__ source/
    \__ index.js
    \__ ...
\__ index.d.ts
\__ license
\__ package.json
\__ readme.md

Avoids the abbreviation problem too, lol

[sindresorhus]

I think it's easier to simply bundle everything. If we do a separate dependencies file, we need to change all the import statements.

[tommy-mitchell]

Whoops, you're right, was thinking a little too fast there.

[tommy-mitchell]

I'm not sure when the build script should be run. Pros and cons:

• prepack:
  • recommended by yarn
  • runs when packages are installed from git
  • also runs when np does checks (e.g. npm pack --dry-run --json)
    • seems like it shouldn't, but I'm not sure
• prepublishOnly:
  • only runs on npm publish
  • doesn't run until needed, but git consumers can't consume meow

[LitoMore]

@tommy-mitchell FYI, Got and Ky are using prepare.

• https://github.com/sindresorhus/got/blob/main/package.json
• https://github.com/sindresorhus/ky/blob/main/package.json

[sindresorhus]

Either prepack or prepare. I generally prefer prepare as it also executes when running npm install while developing.

[tommy-mitchell]

Changes:

• Added an _actualDependencies field to package.json
• Changed output directory to build instead of dist
• Changed build script to use prepare instead of prepack

With Rollup, I was able to separate the dependencies into a separate file and have the imports be updated:

\__ build/
	\__ licenses.md # License of each bundled dependency
	\__ dependencies.js # Vendor bundle
	\__ index.js
	\__ options.js
	\__ parser.js
	\__ utils.js
	\__ validate.js
\__ index.d.ts
\__ license
\__ package.json
\__ readme.md

[sindresorhus]

I guess it doesn't hurt, but kinda weird that each generated file includes:

import 'util';
import 'path';
import 'fs';
import 'url';
import 'node:fs';
import 'os';
import 'node:path';
import 'node:url';
import 'node:process';

[sindresorhus]

Looks pretty good

[sindresorhus]

Have you manually tested it with a CLI to make sure meow still works when published? You can run npm pack and then decompress it in a CLI project.

[tommy-mitchell]

Have you manually tested it

I had before, but I went ahead and added a couple of tests using the built output to verify going forward.

[tommy-mitchell]

I guess it doesn't hurt, but kinda weird that each generated file includes

Yeah I'm not sure what's up with that, I need to do some research.

[tommy-mitchell]

Managed to fix the empty Node builtin imports. I think this should be good to go.

[Grohden]

@sindresorhus @tommy-mitchell
One question about this PR: How does it work with security checks and resolution bumps? Since dependencies are now bundled and not declared in the package.json, security issues with them might not be reported anymore by bots... we will also not be able to properly check if a dependency is updated

In the old version:

➜  project git:(main) ✗ yarn why semver
└─ normalize-package-data@npm:2.5.0
   └─ semver@npm:5.7.2 (via npm:2 || 3 || 4 || 5)
➜  project git:(main) ✗ yarn why normalize-package-data
├─ meow@npm:6.1.1
│  └─ normalize-package-data@npm:2.5.0 (via npm:^2.5.0)
│
└─ read-pkg@npm:5.2.0
   └─ normalize-package-data@npm:2.5.0 (via npm:^2.5.0)

In the new bundled deps version (12.1.1):

➜  project git:(main) ✗ yarn why normalize-package-data
└─ read-pkg@npm:5.2.0
   └─ normalize-package-data@npm:2.5.0 (via npm:^2.5.0)

No report, although normalize-package-data it's being used by meow

Also, how does security issues are auto checked in this repo?

[sindresorhus]

not be reported anymore by bots

I would argue that's an upside. 99% of all npm audits are not actually vulnerabilities (the semver "vulnerability" is a good example of one) or not applicative to meow. So this reduces the noise.

https://overreacted.io/npm-audit-broken-by-design/

[Grohden]

@sindresorhus I agree that audit sucks. Big red "critical" text scares security company monke

But as Dan says "Inlining dependencies kind of goes against the whole point of npm", and I feel like we kinda lose any analysis (you might not only use it for security) tools using that approach:

• I can't know for sure this dep is in my codebase (if its a real issue)
• I can't report it in bundle analysis (it's gonna report meow as a bigger dep)
• I can't use resolutions field to force dependency version (this is somehow a win.. cuz its a nightmare to remember potential issues with the resolutions)
• More potential to duplicate code (ties back to what Dan said)

But in the end it's your decision & opinion as a lib owner, as long as you're aware I think its ok

[sindresorhus]

I generally agree that inlining is bad, but in this specific case, the upsides outweight the downsides.

[fregante]

I'm on the fence with this change… but also I think it would be great to see it on ora, which seems to be super small but in reality:

• https://npmgraph.js.org/?q=ora@7.0.1
• https://packagephobia.com/result?p=ora (more than meow itself, now)

At the end of the day bundling is great for this sort of dependencies, but it does force you to release more often than you normally would. This happens for example when a new node version is out and some old issue now needs to be fixed here as well (with a simple sub-dependency patch update)