ES6 modules and file name suffixes

I was hoping to use bpmn-moddle directly from a browser without going through a packager. I managed to make some progress then ran aground. What I seem to be finding is that the import statements in our code base don’t specify a file type of .js. For example:

import BpmnModdle from './bpmn-moddle';

instead of:

import BpmnModdle from './bpmn-moddle.js';

Being new to modules and still an infant int BPMN-IO packages … I’m hoping that someone with skills in this area can comment? Might this be a change required in how BPMN.IO uses import or might there be something I need to change in my browser side JavaScript?

The general convention is to consume files without the suffix and let the consumer choose the correct file based on the extension. You should attempt to configure your ES module loader in the browser to load .js files per default, falling back to .json, if the .js file is not found.

This way you should be able to consume bpmn-moddle, even though we never tried it out ourselfes.

1 Like

Thank you for the response. If I may ask … is there any harm in adding explicit suffixes to the code base for module names? Would it be “incorrect” in some form to have “bpmn-moddle.js” as opposed to “bpmn-moddle”?

I seem to be finding references to problems being encountered by not having file suffices.




https://www.quora.com/What-file-extension-should-es6+-files-be

Please don’t think for one moment that I am arguing with your comments. I have nowhere near the skills nor authority. I’m merely a happy customer/consumer of your works. If adding explicit “.js” suffices is harmless and makes things work out the box then yeah. If the goal of using natively away from a package manager is sound and there is way to “tell” Chrome how to find the packages it needs (an ES module loader) then yeah again … but I don’t know how to do that (yet).

Right now, the whole JS eco-system is in full shift from non-standardized module systems (CommonJS, AMD, …) to ES modules. Most browsers support ES module resolution, however many library authors do not target that audience yet, as libraries are simply bundled rather than directly loaded via the browser. The later benefits from proper suffix resolution. To give you one example, NodeJS may load either foo.js or foo.mjs depending if the source is a CommonJS or ES module.

If you share an example how you consume bpmn-moddle as ES modules with Chrome I’m happy to play around with it. Maybe there is a simple solution we can offer you to make things work. Maybe bundling is gonna be the workaround for now.

What I was attempting to do was use the module “bpmn-module”. In a JavaScript source file (test.js), I had coded:

import BpmnModdle from 'bpmn-moddle'

In the HTML which I loaded into the latest release of chrome, I had:

<script type="module" src="test.js"></script>

When I ran this, I received the error that we could not find bpmn-moddle. As I dug further, I found that if I changed the JavaScript statement to:

import BpmnModdle from 'bpmn-moddle.js'

I could now make progress. However, since bpmn-moddle.js also performs import requests and those import requests also name modules without file name sufficies, I quickly became challenged. It would seem that I would need to go through all the BPMN.IO source files and add suffices and I was hoping to avoid this. This took me to the study of the state of play of suffixes (yes/no) and if suffices then what suffix? Which brings me to this discussion. My non-expert sense seems to be leaning to the notion that import statements in ES6 should have suffices but BPMN.IO modules don’t. Obviously I could be wrong here and I leave it to good folks like yourself who are much more experienced in these matters to make the correct changes (if any). As of right now, I am “working” by using webpack … but it feels less than optimal as I don’t need nor want a packager in my workflow or solution unless it is absolutely required.