To create a
Node, one must create a
.html file and associated
.js file with the same base name, and they must live in the same directory (as far as I know; this is what the docs say).
Having implemented a few–and having attempted to use “modern” workflows while doing so–I’ve run into some speed bumps due to this restriction.
Nodedeveloper wishing to use ES2015+ features is naturally limited by Node.js v4’s implementation, since that’s the oldest version of Node.js that Node-RED supports.
- To work around this, compilation or transpilation is necessary.
- This generates build artifacts (“dist files”) which typically live in a separate directory (e.g.,
- Build artifacts shouldn’t live in version control.
- Unless an additional script would copy a
.htmlfiles must be under version control and live in
dist/, while the build artifacts are ignored. This is awkward.
- Adding such a workflow to JS living in the
.htmlfile is something I haven’t explored, because it would require nonexistent, particular-to-Node-RED build tooling to output in the structure that NR wants. That isn’t to say this sort of thing couldn’t work (see
.vuefiles as an example where this does work), but it requires tooling.
- The requirement that the front-end JS lives in a
<script>tag in the the
.htmlfile means it’s difficult/impossible to use linters and formatters against it, as well as run isolated unit tests.
- The requirement that the front-end template lives in a
<script>tag in the
.htmlfile can confuse many text editors.
- It’s unclear how to use a 3rd-party front-end view or template library (e.g., React or Handlebars) if so desired. For many simple
Nodes, this isn’t a problem, but others can suffer from an overabundance of jQuery.
The proposal is, then: allow the developer more freedom to specify the paths to each of these components (the backend JS, the frontend JS, and the template body). This would give the developer the means to work towards further solutions. This needn’t be a breaking change.