Build babel regexp based on dependencies

[tooppaaa]

Relates to #24

In order to be 100% sure all dependencies are included in the es6Modules output, I'm assuming we need to do it in multiple steps

• Parse package.json
• Extract dependencies
• Parse yarn.lock (https://www.npmjs.com/package/@yarnpkg/lockfile) / package.lock (https://github.com/snyk/nodejs-lockfile-parser ?)
• build complete dependency list
• run as usual

WDYT ?

[obahareth]

@tooppaaa It's definitely something worth experimenting with, I think the --all option gives the ability to check the whole list of dependencies and might be enough for most cases (unless the list is quite big). Based on #24 I was thinking of including a way to let users select only dependencies or also include dev dependencies, but I haven't gotten around to that yet.

I think that even if we implemented this solution still wouldn't work because of #2, and that's the trickiest part. I built this library with the assumption that if a library is ES6, most likely the entrypoint script would be ES6 but as you can see in this comment that's not always the case, and I am not sure how to tackle this, perhaps we could recurse into scripts required by the entrypoint but only up to a certain depth?

I think a variation of --all perhaps --all-without-dev and also somehow checking scripts included by the entrypoint would give us this 100% certainty, what do you think? I just don't want to sacrifice performance too much.

Also since you're helping out a lot with this repo, do you think you are open to being a maintainer?

[tooppaaa]

Thanks for the maintainer offer ;) definitely going to help a bit :)

I can see different level for this.

1. direct dependencies: check only dependencies from package.json
2. dependencies: previous + dependency tree (yarn.lock, package.lock)
3. all: include all node_modules
4. nuts: entry points + depth in package.

To me, this library helps at the end to create the regexp for a babel loader (which we can also build at some point) where dependencies are not es5.
We have level 1 with the CLI + Node API
We have level 3 with the CLI --all

Level 4 will require caching so I suggest we leave it out of scope for now ? It will be complex and may still not solve the issue. There will be some fancy libraries that goes out of the box but if we manage to cover 95%, it's already a huge win

[obahareth]

Further discussion should happen on #2.