dev command about nanobundle HOT 5 OPEN

I will add nanobundle dev command.

I'd like to mention that the experience design for this is complex compared to other tools. This is because nanobundle doesn't just act as a proxy for tsc, also needs to support multiple entries.

But naively reporting all diagnostics for all entries during development won't work very well. Not necessarily simultaneous. One of the best rules of thumb for a good development experience (especially when refactoring types) is "focus on one problem at a time".

from nanobundle.

I'm more focused on getting the build right in v1. But this will definitely be on my future tasks!

For TypeScript projects, I can imagine a scenario where type-checks are prioritized and then incremental builds are performed if they pass. What would be the ideal dev mode experience imaginable if you weren't using TypeScript?

from nanobundle.

I am replacing watch in the following way. please refer to this.

    "watch": "chokidar \"src/*\" -c \"npm run nano:build\" --polling",

from nanobundle.

Drops some implementation ideas here:

While esbuild's watch and node's fs.watchFile use stats polling, node's fs.watch provides an optimized implementation for each platform, so it would be reasonable to implement based on this.

Also, instead of recursively traversing a specific path, selecting only the modules reachable from the entry point inferred from the manifest effectively narrows the watch and makes better system compatibility. Perhaps it should run esbuild with two-path for this.

from nanobundle.

All entries and their dependencies should be watched in the soon-to-be-added "unbundle" mode (#166).

How about in bundling mode? Typically, we don't test multiple entries at once in development, so maybe we can narrow it down to some of the JS bundle groups.

• the main entry
• exported to subpath
• module format matching package type
• development condition

from nanobundle.