Support Consumption of Non-Webpacked Source Code

[sbulley09]

Are you reporting a feature request or a bug?

Feature Request

Request Details

Currently, the only method of consumption is via the webpacked bundle in the dist folder. This webpack bundle includes a polyfill babel polyfill set up via the usage method. This ends up adding a polyfill for Promises but not for the 'finally' functionality of promises since those are not used within the code. One of our solutions relies on a promise polyfill which is a different polyfill than the provided by babel.

Since the incomplete babel polyfill is loaded first without all the functionality, it doesn't get overwritten by our polypill and thus we end up with the 'finally' functionality missing. As a work around, we've copied the source code into our own project which allows us to use our internal strategy of building projects. This comes with the downside of having to continually update our internal fork over time and maintain that ourselves. It would be ideal for us to be able to consume the non-webpacked source and be able to apply our own polyfills as needed.

[sculpt0r]

Hi @sbulley09 ,

Thank you for the proposal. At this point I can tell that we won't work on such a solution - so I close this issue. Please, notice that we have to provide a complete solution that works in many different environments.

[ryanthemanuel]

Would it be possible to both export the original (or transpiled) files in addition to the webpack bundle? Really, we are looking to do the webpacking ourselves as we have unique needs that aren't being covered by the webpack bundle that this project is providing.

[sculpt0r]

@sbulley09 , @ryanthemanuel 
I talked with @f1ames and we decide to reopen this feature request and take it into a schedule.

[MMMalik]

We can simply publish src folder along dist. Then consumers can do pretty much whatever they want with it. Alternatively, since our component is a fairly typical esm module, we can copy it to dist and expose it via module or esnext field on package.json but I'm not sure it's a fully backward compatible solution (Some existing setups might break? Will webpack default to module instead if main?).

[f1ames]

We can simply publish src folder along dist. Then consumers can do pretty much whatever they want with it.

We were thinking about such solution. Theoretically, one can simply use GitHub repo with stable branch to get latest dev version. OTOH it would be more convenient to have it in npm module. 

 Alternatively, since our component is a fairly typical esm module, we can copy it to dist and expose it via module or esnext field on package.json but I'm not sure it's a fully backward compatible solution (Some existing setups might break? Will webpack default to module instead if main?).

I guess this would be more "proper" solution so it can be consumed easier as it's integrated into standard workflows. Not sure about backwards compatibility and webpack though 🤔 @Comandeer WDYT?

[f1ames]

Hi @sbulley09 and @ryanthemanuel,

This is already covered in new RC version available already on NPM. Feel free to check how it works - your feedback on this is more than welcome. You can find documentation on a new version here.

[f1ames]

Hi @sbulley09 and @ryanthemanuel,

The RC version previously mentioned in #180 (comment) has been released as stable 2.0.0 version today so you can use it for production.

Fixed in 2.0.0 version (f03dde8 and https://www.npmjs.com/package/ckeditor4-react/v/2.0.0).