-
Notifications
You must be signed in to change notification settings - Fork 40
Generate correct manifest #540
Comments
I'd start by |
I think we will be lucky, because it was mostly needed for the ES6 module flags hack (the loader needed to know in advance if a module was transpiled from ES6). But now that we are bundling everything with webpack, I think that's not needed any more. However, I'm still investigating. |
Right now we are using the
I think 2 was needed for the bridges functionality, which mapped unversioned package names to a specific version to maintain backwards compatibility with the pre-bundler architecture. As far as I can tell, we don't need 1 because we can't have circular dependencies in the current setup. I'm unsure if we could end up having circular deps via imports, but I think we can delay that and, if it happens, we just need to add the necessary flags to the Regarding 2, it is normally not needed, but any module using bridges will need the manifest to be present so I would say we should generate it as in bundler 2, at least until we get rid of bridges... |
Just to give an example of 2: Liferay.Loader.require('frontend-js-web/liferay/events') without any need to specify the current Liferay.Loader.require('[email protected]/liferay/events') |
IIUC, that sounds reasonable. |
Bundler 3 is not generating flags and information for modules in
manifest.json
any more. We should do it (or at least know if it is OK that it is missing) to maintain backwards compatibility.The text was updated successfully, but these errors were encountered: