duct-framework / server.figwheel

Integrant methods for running Figwheel
4 stars 8 forks source link

Fix NullPointerException when processing externs files #8

Open iarenaza opened 3 years ago

iarenaza commented 3 years ago

lein-figwheel expects that all files with .js extension inside its source directories are foreign libraries. And foreign libraries must declare a namespace. In fact, lein-figwheel assumes all .js files have such a namespace declared. And it blindly tries to use it to map the .js file back to a source .cljs file. When the namespace is not declared in the .js file, lein-figwheel bombs out with a NullPointerException when it tries to check if the the source .cljs file exists.

This might happen when you put your externs file(s) inside the source directories (this is our case, e.g. https://github.com/magnetcoop/hydrogen-ce/blob/master/src/hyd/client/externs.js)

lein-figwheel doesn't try to process such files by default on its own. But when using Duct server.figwheel, it tells lein-figwheel to process all files inside the configured source directories (see https://github.com/duct-framework/server.figwheel/blob/master/src/duct/server/figwheel.clj#L54-L55).

Clearly lein-figwheel should be more robust and handle that situation in a more graceful way[1]. On the other hand Duct server.figwheel shouldn't be telling lein-figwheel to process absolutely all files in source directories. It doesn't make sense to process .clj files, .edn files, etc. Probably just those having .cljs/.cljc extension and those declared as foreign libraries.

In issue #7 James Reeves suggested that instead of hard-coding the list of files to process by lein-figwheel, we should have configurable options with default values. And he suggested using a regular expression for matching filenames.

[1] We opened a pull request in lein-figwheel regarding this behaviour, see bhauman/lein-figwheel#739. It has been fixed since then and included in figwheel-sidecar 0.5.20. But Duct server.figwheel is still using figwheel-sidecar 0.5.18

atomist[bot] commented 3 years ago

Commit messages of this repository should follow the seven rules of a great Git commit message, as mentioned in the project's contributing guidelines. It looks like there's a few issues with the commit messages in this pull request: