dev command

[acao]

I see that there is a no-op todo message for this flag! What issues do you foresee with implementing a build watcher?

Here is some prior art:

https://github.com/search?q=repo%3Aegoist%2Ftsup%20watch&type=code

of course it has more complexity to concern itself with than we do with only esbuild, but it's a start. also I don't see this implementation utilizing rebuild method that esbuild returns to make incremental builds work

I would be happy to help contribute this as part of our graphql/graphiql#2925 effort

[cometkim]

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?

[cometkim]

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".

[easylogic]

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

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

[cometkim]

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.

[cometkim]

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