discourse/app/assets/javascripts/pretty-text/package.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

51 lines
1.3 KiB
JSON
Raw Normal View History

{
"name": "pretty-text",
"version": "1.0.0",
"description": "Discourse's text rendering pipeline",
"author": "Discourse",
"license": "GPL-2.0-only",
"keywords": [
"ember-addon"
],
"scripts": {
"build": "ember build",
"lint:hbs": "ember-template-lint .",
"lint:js": "eslint .",
"start": "ember serve"
},
"dependencies": {
"discourse-common": "1.0.0",
"ember-auto-import": "^2.6.3",
"ember-cli-babel": "^8.1.0",
DEV: move xss dependency into core (#23094) This resolves the issue in #23064. This issue arises because we need to produce the trees for the auxilary bundles in `ember-cli-build.js` to pass these trees as argument to `app.toTree()`. In order to produce these trees, the code internally need to set up babel, which deep-clones the addons' babel configs. When using `@embroider/macros`, the addon's babel config includes a `MacrosConfig` object which is not supposed to be touched until the configs are "finalized". In a classic build, the finalization step happens when `app.toTree()` is called. In Embroider, this happens somewhere deeper inside `CompatApp`. We need to produce these auxilary bundle trees before we call `app.toTree()` or before constructing `CompatApp` because they need to be passed as arguments to these functions. So this poses a tricky chicken-and-egg timing issue. It was difficult to find a workaround for this that works for both the classic and Embroider build pipeline. Of all the internal addons that uses the auxilary bundle pattern, this only affets `pretty-text` as it is (for now, at least) the only addon that uses `@embroider/macros`. Taking a step back, the only reason (for now, at least) it was introduced was for the loader shim for the `xss` package. This package is actually used inside the lazily loaded markdown-it bundle. However, we didn't have a better way to include the dep into the lazy bundle directly, so it ends up going into the main addon tree, and, inturns, the discourse core bundle. In core's main loader shim manifest, we already have an entry for `xss`. This was perhaps a mistake at the time, but it doesn't make a difference – as mentioned above, `xss` needs to be included into the main bundle anyway. So, for now, the simpliest solution is to avoid `@embroider/macros` in these internal addons for the time being. Ideally we would soon absorb these back into core as lazily loaded (`import()`-ed) code managed by Webpack when we fully switch over to Embroider.
2023-08-15 23:13:26 +08:00
"ember-cli-htmlbars": "^6.3.0"
},
"devDependencies": {
"@babel/core": "^7.23.0",
"@ember/optional-features": "^2.0.0",
"@ember/string": "^3.1.1",
"@embroider/test-setup": "^3.0.1",
"@glimmer/component": "^1.1.2",
"broccoli-asset-rev": "^3.0.0",
"ember-cli": "~5.0.0",
"ember-cli-inject-live-reload": "^2.1.0",
"ember-cli-sri": "^2.1.1",
"ember-cli-terser": "^4.0.2",
"ember-disable-prototype-extensions": "^1.1.3",
"ember-load-initializers": "^2.1.1",
2023-06-26 22:14:27 +08:00
"ember-resolver": "^10.1.1",
"ember-source": "~3.28.12",
"ember-source-channel-url": "^3.0.0",
"loader.js": "^4.7.0",
"markdown-it": "^13.0.1",
"webpack": "^5.88.2"
},
"engines": {
"node": "16.* || >= 18",
"npm": "please-use-yarn",
"yarn": ">= 1.21.1"
},
"ember": {
"edition": "default"
}
}