2021-01-19 05:12:45 +08:00
|
|
|
{
|
|
|
|
|
"name": "discourse",
|
|
|
|
|
"version": "0.0.0",
|
|
|
|
|
"private": true,
|
2022-08-18 06:27:16 +08:00
|
|
|
"description": "A platform for community discussion. Free, open, simple.",
|
|
|
|
|
"license": "GPL-2.0-only",
|
|
|
|
|
"author": "Discourse",
|
2021-01-19 05:12:45 +08:00
|
|
|
"directories": {
|
|
|
|
|
"doc": "doc",
|
|
|
|
|
"test": "tests"
|
|
|
|
|
},
|
|
|
|
|
"scripts": {
|
|
|
|
|
"build": "ember build",
|
|
|
|
|
"start": "ember serve",
|
2023-04-12 20:15:53 +08:00
|
|
|
"test": "ember test",
|
2023-09-14 19:25:06 +08:00
|
|
|
"postinstall": "../run-patch-package"
|
2021-01-19 05:12:45 +08:00
|
|
|
},
|
2021-08-27 05:19:44 +08:00
|
|
|
"dependencies": {
|
2023-03-24 06:20:33 +08:00
|
|
|
"@glimmer/syntax": "^0.84.3",
|
2022-11-16 16:10:58 +08:00
|
|
|
"discourse-hbr": "1.0.0",
|
|
|
|
|
"discourse-widget-hbs": "1.0.0",
|
2023-05-05 07:02:51 +08:00
|
|
|
"ember-source": "~3.28.12",
|
2023-08-02 07:07:36 +08:00
|
|
|
"handlebars": "^4.7.8",
|
2023-06-30 19:01:45 +08:00
|
|
|
"pretty-text": "1.0.0"
|
2023-04-20 20:57:40 +08:00
|
|
|
},
|
|
|
|
|
"devDependencies": {
|
2023-09-15 07:00:18 +08:00
|
|
|
"@babel/core": "^7.22.19",
|
|
|
|
|
"@babel/standalone": "^7.22.19",
|
2023-08-25 19:44:26 +08:00
|
|
|
"@colors/colors": "^1.6.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"@discourse/backburner.js": "^2.7.1-0",
|
|
|
|
|
"@discourse/itsatrap": "^2.0.10",
|
|
|
|
|
"@ember-compat/tracked-built-ins": "^0.9.1",
|
|
|
|
|
"@ember/jquery": "^2.0.0",
|
|
|
|
|
"@ember/legacy-built-in-components": "^0.4.2",
|
2023-05-03 16:25:13 +08:00
|
|
|
"@ember/optional-features": "^2.0.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"@ember/render-modifiers": "^2.1.0",
|
|
|
|
|
"@ember/string": "^3.1.1",
|
|
|
|
|
"@ember/test-helpers": "^2.9.4",
|
DEV: introduce Embroider behind a flag, and start testing in CI (#23005)
Discourse core now builds and runs with Embroider! This commit adds
the Embroider-based build pipeline (`USE_EMBROIDER=1`) and start
testing it on CI.
The new pipeline uses Embroider's compat mode + webpack bundler to
build discourse code, and leave everything else (admin, wizard,
markdown-it, plugins, etc) exactly the same using the existing
Broccoli-based build as external bundles (<script> tags), passed
to the build as `extraPublicTress` (which just means they get
placed in the `/public` folder).
At runtime, these "external" bundles are glued back together with
`loader.js`. Specifically, the external bundles are compiled as
AMD modules (just as they were before) and registered with the
global `loader.js` instance. They expect their `import`s (outside
of whatever is included in the bundle) to be already available in
the `loader.js` runtime registry.
In the classic build, _every_ module gets compiled into AMD and
gets added to the `loader.js` runtime registry. In Embroider,
the goal is to do this as little as possible, to give the bundler
more flexibility to optimize modules, or omit them entirely if it
is confident that the module is unused (i.e. tree-shaking).
Even in the most compatible mode, there are cases where Embroider
is confident enough to omit modules in the runtime `loader.js`
registry (notably, "auto-imported" non-addon NPM packages). So we
have to be mindful of that an manage those dependencies ourselves,
as seen in #22703.
In the longer term, we will look into using modern features (such
as `import()`) to express these inter-dependencies.
This will only be behind a flag for a short period of time while we
perform some final testing. Within the next few weeks, we intend
to enable by default and remove the flag.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
2023-09-07 20:15:43 +08:00
|
|
|
"@embroider/compat": "^3.2.1",
|
|
|
|
|
"@embroider/core": "^3.2.1",
|
2023-08-09 19:04:41 +08:00
|
|
|
"@embroider/macros": "^1.13.1",
|
DEV: introduce Embroider behind a flag, and start testing in CI (#23005)
Discourse core now builds and runs with Embroider! This commit adds
the Embroider-based build pipeline (`USE_EMBROIDER=1`) and start
testing it on CI.
The new pipeline uses Embroider's compat mode + webpack bundler to
build discourse code, and leave everything else (admin, wizard,
markdown-it, plugins, etc) exactly the same using the existing
Broccoli-based build as external bundles (<script> tags), passed
to the build as `extraPublicTress` (which just means they get
placed in the `/public` folder).
At runtime, these "external" bundles are glued back together with
`loader.js`. Specifically, the external bundles are compiled as
AMD modules (just as they were before) and registered with the
global `loader.js` instance. They expect their `import`s (outside
of whatever is included in the bundle) to be already available in
the `loader.js` runtime registry.
In the classic build, _every_ module gets compiled into AMD and
gets added to the `loader.js` runtime registry. In Embroider,
the goal is to do this as little as possible, to give the bundler
more flexibility to optimize modules, or omit them entirely if it
is confident that the module is unused (i.e. tree-shaking).
Even in the most compatible mode, there are cases where Embroider
is confident enough to omit modules in the runtime `loader.js`
registry (notably, "auto-imported" non-addon NPM packages). So we
have to be mindful of that an manage those dependencies ourselves,
as seen in #22703.
In the longer term, we will look into using modern features (such
as `import()`) to express these inter-dependencies.
This will only be behind a flag for a short period of time while we
perform some final testing. Within the next few weeks, we intend
to enable by default and remove the flag.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
2023-09-07 20:15:43 +08:00
|
|
|
"@embroider/webpack": "^3.1.5",
|
2023-06-30 19:01:45 +08:00
|
|
|
"@glimmer/component": "^1.1.2",
|
|
|
|
|
"@glimmer/tracking": "^1.1.2",
|
|
|
|
|
"@popperjs/core": "^2.11.8",
|
2023-07-03 08:07:34 +08:00
|
|
|
"@uppy/aws-s3": "3.0.6",
|
2023-06-30 12:05:19 +08:00
|
|
|
"@uppy/aws-s3-multipart": "3.1.3",
|
2023-06-29 23:08:33 +08:00
|
|
|
"@uppy/core": "3.0.4",
|
|
|
|
|
"@uppy/drop-target": "2.0.1",
|
2023-08-30 10:50:46 +08:00
|
|
|
"@uppy/utils": "5.4.3",
|
2023-06-29 23:08:33 +08:00
|
|
|
"@uppy/xhr-upload": "3.1.1",
|
2023-08-09 17:47:43 +08:00
|
|
|
"a11y-dialog": "8.0.1",
|
2023-06-30 19:01:45 +08:00
|
|
|
"admin": "1.0.0",
|
2023-07-17 08:58:46 +08:00
|
|
|
"babel-import-util": "^1.4.1",
|
2023-08-24 22:36:22 +08:00
|
|
|
"babel-plugin-ember-template-compilation": "^2.2.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"bootstrap": "3.4.1",
|
|
|
|
|
"bootstrap-json": "1.0.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"broccoli-asset-rev": "^3.0.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"deepmerge": "^4.3.1",
|
2023-07-19 02:07:20 +08:00
|
|
|
"deprecation-silencer": "1.0.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"dialog-holder": "1.0.0",
|
|
|
|
|
"discourse-common": "1.0.0",
|
|
|
|
|
"discourse-plugins": "1.0.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"ember-auto-import": "^2.6.3",
|
2023-06-30 19:01:45 +08:00
|
|
|
"ember-buffered-proxy": "^2.1.1",
|
2023-07-27 10:56:03 +08:00
|
|
|
"ember-cached-decorator-polyfill": "^1.0.2",
|
2023-06-26 23:15:59 +08:00
|
|
|
"ember-cli": "~5.0.0",
|
2023-06-16 07:38:49 +08:00
|
|
|
"ember-cli-app-version": "^6.0.1",
|
2023-08-21 17:27:24 +08:00
|
|
|
"ember-cli-babel": "^8.0.0",
|
2023-04-20 20:57:40 +08:00
|
|
|
"ember-cli-deprecation-workflow": "^2.1.0",
|
2023-08-09 17:26:42 +08:00
|
|
|
"ember-cli-htmlbars": "^6.3.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"ember-cli-inject-live-reload": "^2.1.0",
|
|
|
|
|
"ember-cli-progress-ci": "1.0.0",
|
|
|
|
|
"ember-cli-sri": "^2.1.1",
|
|
|
|
|
"ember-cli-terser": "^4.0.2",
|
2023-06-30 19:01:45 +08:00
|
|
|
"ember-decorators": "^6.1.1",
|
2023-06-23 04:54:46 +08:00
|
|
|
"ember-exam": "^8.0.0",
|
2023-08-04 07:04:09 +08:00
|
|
|
"ember-functions-as-helper-polyfill": "^2.1.2",
|
2023-06-30 19:01:45 +08:00
|
|
|
"ember-load-initializers": "^2.1.1",
|
|
|
|
|
"ember-modifier": "^4.1.0",
|
Upgrade ember-on-resize-modifier (#23045)
The previous version of ember-on-resize-modifier depended on
ember-modifier@^3.2.7 while discourse had ember-modifier@^4.1.0.
As far as Yarn is concerned, it can accomplish this with:
node_modules
...
ember-modifier 4.1.0
...
ember-on-resize-modifier 1.1.0
...
ember-modifier 3.2.7
...
...
This does NOT work!
In a classic build everything is compiled down to AMD modules and
at runtime there can only be one uniquely named "ember-modifier"
module. When we have duplicates, depending on activation ordering,
one of them will randomly win.
In practice, it seems like ember-modifier 3.2.7 had "won" in the
current build, and we are shipping it to production, you can find
these modules in vendor.js like:
```js
;define("ember-modifier/-private/class/modifier", /* ... */, function(/* ... */) {
/* the 3.2.7 version with deprecations, etc */
})
/* ... */
;define("ember-modifier/index", /* ... */)
```
However, ember-auto-import also "found" the 4.1.0 version and in
one of the chunk.app.js:
```js
d('ember-modifier', /* ... */, function() { return __webpack_require__(/*! ember-modifier */ 227); });
```
...and in one of the chunk.vendors.js...
```js
/* 227 */
/*!****************************************************!*\
!*** ../node_modules/ember-modifier/dist/index.js ***!
\****************************************************/
/***/ ((__unused_webpack_module, __webpack_exports__, __webpack_require__) => {
"use strict";
/* ...the 4.1.0 version... */
}),
```
So, in practice:
* We are brining both copies into the production build
* The 3.2.7 modules are available in the AMD loader as "ember-modifier/..."
* But 4.1.0 modules are available in the AMD loader as "ember-modifier"
* Because mostly it's consumed as `import ... from "ember-modifier";`, the
latter end up actually winning
* Because the newer code is compatible enough, and the deprecated features
are unused, it seems to work ok..?
But in the Embroider build, ember-auto-import doesn't emit those shims
anymore. It does process most of the core modules through Webpack so the
imports get correctly wired up to the 4.1.0 as expected, as they no longer
go through/need the runtime AMD loader.js.
The older 3.2.7 copy is _still_ shipped in the vendor bundle and registered
the same, but not "stomped over" by the EAI shims anymore. Our manual shims
(#22703, merged yesterday) are more "polite" and check `require.has(...)`
before defining the module, and since `require.has(...)` check for the
`/index` alias and returns `true`, our shim does not stomp the 3.2.7 modules
either.
So then, when our "auxilary bundles" (admin, plugins, etc) tries to import
`"ember-modifier", they get the 3.2.7 version.
2023-08-10 17:28:39 +08:00
|
|
|
"ember-on-resize-modifier": "^2.0.2",
|
2023-06-30 19:01:45 +08:00
|
|
|
"ember-production-deprecations": "1.0.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"ember-qunit": "^6.2.0",
|
2023-08-25 16:32:54 +08:00
|
|
|
"ember-router-service-refresh-polyfill": "^1.1.0",
|
2023-07-21 04:01:12 +08:00
|
|
|
"ember-template-imports": "^3.4.2",
|
2023-06-30 19:01:45 +08:00
|
|
|
"ember-test-selectors": "^6.0.0",
|
2023-09-25 16:13:52 +08:00
|
|
|
"eslint": "^8.50.0",
|
2023-06-29 07:09:34 +08:00
|
|
|
"eslint-plugin-qunit": "^8.0.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"html-entities": "^2.4.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"imports-loader": "^4.0.1",
|
2023-06-30 19:01:45 +08:00
|
|
|
"js-yaml": "^4.1.0",
|
|
|
|
|
"jsdom": "^22.1.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"loader.js": "^4.7.0",
|
2023-08-15 10:20:55 +08:00
|
|
|
"message-bus-client": "^4.3.8",
|
2023-06-30 19:01:45 +08:00
|
|
|
"messageformat": "0.1.5",
|
2023-05-03 16:25:13 +08:00
|
|
|
"pretender": "^3.4.7",
|
2023-06-23 04:54:46 +08:00
|
|
|
"qunit": "^2.19.4",
|
|
|
|
|
"qunit-dom": "^2.0.0",
|
2023-08-21 17:01:16 +08:00
|
|
|
"sass": "^1.66.1",
|
2023-06-30 19:01:45 +08:00
|
|
|
"select-kit": "1.0.0",
|
2023-09-14 07:04:14 +08:00
|
|
|
"sinon": "^16.0.0",
|
2023-05-03 16:25:13 +08:00
|
|
|
"source-map": "^0.7.4",
|
2023-09-05 06:28:38 +08:00
|
|
|
"terser": "^5.19.4",
|
2023-09-13 01:55:12 +08:00
|
|
|
"tippy.js": "^6.3.7",
|
2023-07-21 04:01:12 +08:00
|
|
|
"truth-helpers": "1.0.0",
|
2023-06-30 19:01:45 +08:00
|
|
|
"util": "^0.12.5",
|
|
|
|
|
"virtual-dom": "^2.1.1",
|
2023-07-18 17:35:46 +08:00
|
|
|
"webpack": "^5.88.2",
|
2023-06-30 19:01:45 +08:00
|
|
|
"wizard": "1.0.0",
|
2023-06-12 19:28:40 +08:00
|
|
|
"workbox-cacheable-response": "^7.0.0",
|
|
|
|
|
"workbox-core": "^7.0.0",
|
|
|
|
|
"workbox-expiration": "^7.0.0",
|
|
|
|
|
"workbox-routing": "^7.0.0",
|
|
|
|
|
"workbox-strategies": "^7.0.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
|
|
|
"workbox-sw": "^7.0.0",
|
|
|
|
|
"xss": "^1.0.14"
|
2023-06-30 19:01:45 +08:00
|
|
|
},
|
|
|
|
|
"engines": {
|
|
|
|
|
"node": "16.* || >= 18",
|
|
|
|
|
"npm": "please-use-yarn",
|
|
|
|
|
"yarn": ">= 1.21.1"
|
|
|
|
|
},
|
|
|
|
|
"ember": {
|
2023-07-18 17:00:19 +08:00
|
|
|
"edition": "octane"
|
2021-01-19 05:12:45 +08:00
|
|
|
}
|
|
|
|
|
}
|