-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MERGE] *: Add support for native JS modules and sourcemaps #63177
Conversation
368cd39
to
cbae023
Compare
ca4b8b7
to
e4f160c
Compare
b04ac31
to
db1b1c7
Compare
900607e
to
8e65995
Compare
a03ad34
to
4f35b61
Compare
885cfda
to
4e3c94b
Compare
08713d5
to
e81ef04
Compare
19e8b94
to
d8c6195
Compare
d4245a9
to
ceb39db
Compare
8e9e1aa
to
a07b87e
Compare
a07b87e
to
689ed7d
Compare
robodoo r+ |
@ged-odoo, you may want to rebuild or fix this PR as it has failed CI. |
robodoo merge |
Merge method set to merge directly, using the PR as merge commit message |
@robodoo override=ci/style
|
addons/web/controllers/main.py
Outdated
'/web/content/<int:id>/<string:filename>', | ||
'/web/content/<int:id>-<string:unique>', | ||
'/web/content/<int:id>-<string:unique>/<string:filename>', | ||
'/web/content/<int:id>-<string:unique>/<path:extra>/<string:filename>', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason for dropping these alternative routes? In particular, the /web/content/<int:id>/<string:filename>
looks like it may be useful outside of the context of assets, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only the desire to simplify as much as possible. Do you want to add them back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addons/web/controllers/main.py
Outdated
def content_assets(self, xmlid=None, model='ir.attachment', id=None, field='datas', | ||
filename=None, filename_field='name', unique=None, mimetype=None, | ||
download=None, data=None, token=None, access_token=None, **kw): | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, on the other hand, I would only accept the parameters that we know we'll be using. e.g. not xmlid
, model
, field
, filename_field
, token
, access_token
, mimetype
, download
, ...
Since this is a new route dedicated to assets there's no legacy to support for other URL patterns. If we accept more parameters now, it may make it harder to implement more asset-specific logic in the future.
It will also avoid potential security-related issues related to model
, token
, etc. in the future, as we don't want to open more doors here that strictly necessary.
**kw
is kept to support extra params like debug=xxx
without crashing, but we ignore query string params we don't need to accept.
def content_assets(self, xmlid=None, model='ir.attachment', id=None, field='datas', | |
filename=None, filename_field='name', unique=None, mimetype=None, | |
download=None, data=None, token=None, access_token=None, **kw): | |
def content_assets(self, id=None, filename=None, unique=None, extra=None, **kw): | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good time to make extra
a named parameter too, no?
Linked pull request(s) odoo/enterprise#16181, odoo/upgrade#2154 not ready. Linked PRs are not staged until all of them are ready. |
Because of the way Odoo works at its core, we do not know before hand which files will be loaded as an asset in the browser, because it depends on the installed Odoo addons. This is why it is historically difficult to integrate Odoo with standard JS tooling, and this is why Odoo needs to use a custom javascript module system. However, there is a way to use native JS modules (and gain all the benefits from it: IDE autocompletion, ease of refactoring, intellisense, ...): we can write JS as native JS modules, but convert them at runtime into Odoo custom modules. This is exactly the strategy applied by this PR. This has a lot of benefits, but there is a downside: we can no longer serve statically JS files in debug=assets. This would be a dealbreaker, if we did not have sourcemaps (implemented in the next commit). This commit introduces the python code that will transpile native JS modules into odoo JS modules. Task ID: 2414902 PR: 63177 Co-authored-by: Francois (fge) <fge@odoo.com>
Because of the previous commit introducing support for native JS modules, it is no longer possible to serve statically JS files in debug=assets mode. Because of that, we serve a (non minified) bundle instead, but with sourcemaps. This commit contains the code for the sourcemap generator. Part of PR 63177 Co-authored-by: Simon Genin (ges) <ges@odoo.com>
With the new native JS module system, we have a lot of new features for the developer: autocompletion, docstrings, ... However, it does not work across modules: if a JS file in /addons/stock/static/src/some_file.js want to import a file in web, say /addons/web/static/src/blabla.js, we will need to use a statement like this: import { something } from '@web/blabla'; Obviously, there is no automatic way for IDEs to know that '@web' should map to 'addons/web'. This is why we propose to use a tsconfig.json that defines the mapping between modules and their paths. This is not mandatory, and only affects those developers that work commonly in JS. Part of PR 63177 Co-authored-by: Francois (fge) <fge@odoo.com>
The previous work on adding support for native JS modules needs to adapt some existing files, which have an incompatible name (with a '/'). Also, we convert a few JS file in /web to the native JS module system, to show that it can work. Part of PR 63177 Co-authored-by: Simon Genin (ges) <ges@odoo.com>
1bdd17c
to
e49a9b2
Compare
robodoo r+ |
Part of PR 63177
e49a9b2
to
402740f
Compare
robodoo r+ |
Because of the way Odoo works at its core, we do not know before hand
which files will be loaded as an asset in the browser, because it
depends on the installed Odoo addons. This is why it is historically
difficult to integrate Odoo with standard JS tooling, and this is why
Odoo needs to use a custom javascript module system.
However, there is a way to use native JS modules (and gain all the
benefits from it: IDE autocompletion, ease of refactoring, intellisense,
...): we can write JS as native JS modules, but convert them at runtime
into Odoo custom modules. This is exactly the strategy applied by this
PR.
This has a lot of benefits, but there is a downside: we can no longer
serve statically JS files in debug=assets. This would be a dealbreaker,
if we did not have sourcemaps.
So, this PR introduces
/web/assets/
Note that part of the complexity of this work is cause by the debug=assets mode, where we need to have a fixed route for the debug asset bundle (so we do not lose breakpoints when debugging), but we still need to safely regenerate the bundles whenever the JS code is modified.