Skip to content
This repository was archived by the owner on Oct 17, 2020. It is now read-only.

Generate correct manifest #540

Closed
izaera opened this issue Mar 10, 2020 · 5 comments
Closed

Generate correct manifest #540

izaera opened this issue Mar 10, 2020 · 5 comments
Assignees

Comments

@izaera
Copy link
Member

izaera commented Mar 10, 2020

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.

@izaera izaera added this to the IFI-851 | Bundler 3.x milestone Mar 10, 2020
@jbalsas
Copy link
Contributor

jbalsas commented Mar 10, 2020

I'd start by know if it is OK that it is missing... it's always been hard for my to figure out wether this is needed or not...

@izaera
Copy link
Member Author

izaera commented Mar 10, 2020

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.

@izaera izaera self-assigned this Mar 10, 2020
@izaera
Copy link
Member Author

izaera commented Mar 10, 2020

Right now we are using the manifest.json for two things:

  1. Add module flags (as per Add support for writing module metadata in manifest.json #368): needed for circular dependencies, but can be used as a general mechanism to pass metadata regarding modules from the JS Toolkit directly to the NPM Registry.
  2. Map namespaced module names: for example react to frontend-js-web-react$react.

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 manifest.json file.

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...

Any thoughts? @jbalsas @wincent

@izaera
Copy link
Member Author

izaera commented Mar 10, 2020

Just to give an example of 2: frontend-js-web declares bridges in the .npmbridgerc file to map all the frontend-js-web/liferay/* modules to an unversioned name, so that people can do:

Liferay.Loader.require('frontend-js-web/liferay/events')

without any need to specify the current frontend-js-web version like in:

Liferay.Loader.require('[email protected]/liferay/events')

@wincent
Copy link
Contributor

wincent commented Mar 10, 2020

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...

IIUC, that sounds reasonable.

izaera pushed a commit to izaera/liferay-js-toolkit that referenced this issue Mar 10, 2020
@izaera izaera closed this as completed Mar 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants