Support usage without a Bundler

I JavaScript bundler like Parcel is recommended by the documentation. In fact not using a bundler leads to some errors.

While using a bundler has many advantages, sometimes it is useful to not having to use a bundler.

• Configuring a bundler add an additional layer.
• A bundler needs to be installed and configured. A bundler can has it own errors.
• Bundled JavaScript is more complicated to debug if everything gets wrapped in a IIFE.
• While bundling files for production, in development, the opposite can be true. Recompling after every change of a file can slow down development.

Over all, having the option to not use a bundler would be nice. A documentation for that would be great.

I guess this takes minimal code changes. If I am not mistaken, ol should not use “bare” imports like import { easeOut } from './easing'; but import { easeOut } from './easing.js';. But I do not really know what there is to do to achieve that.

[tschaub]

Isn’t this a counter example?

There are some others examples and I think this is one reason, why it is not working that way.

Yes indeed. We started out trying to be consistent, but as you point out, there is now lots of inconsistency. I put together #9615 to bring consistency and a linter rule that errors if we don’t include the file extension.

However, “bare” import specifiers still don’t work “out of the box” in browsers. So you cannot do this for example:

import PBF from 'pbf';

And that is how we import 3rd party dependencies in the library.

[mogoh]

Thank you for your help. I am not that experienced this JavaScript so bear with me, if I say something stupid.

@mogoh, for what it’s worth, the library already uses proper relative paths in our import specifiers (explicit, not implied file extensions; no “directory” imports with implied index files).

@tschaub Isn’t this a counter example?

There are some others examples and I think this is one reason, why it is not working that way.

So, the library is ready for unbundled use, but as @ThomasG77 points out, the same is not true of browsers and the JS modules ecosystem.

Well, for me for now it is sufficient if my development browser supports it. The generall JS ecosystem on the other hand is of course a different problem.

The library has dependencies that are not all published with the same rules we follow (proper relative paths).

rbush is an example, that, if I am not mistaken, just fixed that problem with version 3.0.0. rbush 3.0.0 is used now at the openlayers master branch. So there is no problem here (if again I am not mistaken). So, is there any other external library missing?

Even if this were the case, bundling and minification is still recommended.

Our general recommendation is to continue using bundlers before deploying modules to production. In a way, bundling is a similar optimization to minifying your code: it results in a performance benefit, because you end up shipping less code. Bundling has the same effect! Keep bundling.

While it adds extra overhead to the development process, getting comfortable using a bundler has benefits.

Yes, I will still use a bundler if my code is ready for production. The reason I am so unhappy with bundling is, that it makes debugging a bit more complicated. If my code runs unbundled than I am sure, it should run bundled or else bundling went wrong.

I know that bundling has been obligatory for years now and you JS developers are very familiar with it. I just think that we are (almost) at a point where bundling is not necessary and if we just go this extra step, we can have some extra benefits.