Skip to content
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

Make CKEditor 5 packages valid ESM #13673

Closed
Assignees
Labels
domain:integration-dx This issue reports a problem with the developer experience when integrating CKEditor into a system. squad:core Issue to be handled by the Core team. support:2 An issue reported by a commercially licensed client. type:question This issue asks a question (how to...).

Comments

@pomek
Copy link
Member

pomek commented Mar 14, 2023

📝 Provide a description of the improvement

To use CKEditor 5 sources in Node without processing it by any bundler, we can mark our packages as type:module in package.json.

There's another issue that is just quasy rellated to this:

When using ckeditor from sources without a build, vitest (being esm-first project) complains about CK5 modules not being esm modules, although they seem to should be in its opinion.

Module /Users/sitecore/Sites/feaas-components/ckeditor5/node_modules/@ckeditor/ckeditor5-utils/src/dom/findclosestscrollableancestor.js:14 
seems to be an ES Module but shipped in a CommonJS package. 
You might want to create an issue to the package "@ckeditor/ckeditor5-utils" 
asking them to ship the file in .mjs extension or add "type": "module" in their package.json.

Is this something that can be resolved?

Originally posted by @Inviz in #11704 (comment)

As it is unrelated to TypeScript migration (our sources were modules before migration), I extracted the discussion to another issue.


If you'd like to see this improvement implemented, add a 👍 reaction to this post.

@pomek pomek added type:question This issue asks a question (how to...). pending:feedback This issue is blocked by necessary feedback. labels Mar 14, 2023
@Inviz
Copy link
Contributor

Inviz commented Mar 14, 2023

Thanks @pomek . It does seem like that would resolve the problem. It makes sense too.

@HaNdTriX
Copy link

HaNdTriX commented May 10, 2023

Is there any workaround regarding this issue?
Adding

File: vite.config.ts

  test: {
    ...
+    deps: {
+      inline: [
+        'ckeditor5'
+      ]
+    }
  }

doesn't seem to work.

@Witoso Witoso added squad:devops Issue to be handled by the Devops team. squad:core Issue to be handled by the Core team. domain:integration-dx This issue reports a problem with the developer experience when integrating CKEditor into a system. labels May 12, 2023
@Witoso
Copy link
Member

Witoso commented May 12, 2023

Noticed the same, I'm not sure why inlining ckeditor5 works for our standard packages but doesn't work for RealTimeCollaborativeEditing.

For now, it's a good workaround if you're not using Collaboration:

export default {
  test: {
    deps: {
      inline: [
        "ckeditor5",
        /ckeditor5/
      ],
    },
  },
};

@filipsobol
Copy link
Member

filipsobol commented May 19, 2023

Adding "type": "module" changes not only how our package is consumed, but also how our tools and Node interpret and execute the code.

With "type": "module" all .js files are expected to use ESM. This causes problems with the webpack config file which uses CJS. Renaming all webpack.config.js files to webpack.config.cjs fixed this.

Another problem was caused by webpack requiring file extensions in imports in manual and automated tests.

Manual tests can be fixed by updating the getJavaScriptLoader function in @ckeditor/ckeditor5-dev-utils to return the following object:

return {
  test: /\.js$/,
  ...getDebugLoader( debugFlags ),
+  resolve: {
+    fullySpecified: false,
+  }
};

The same problem can be fixed for automated tests by adding the following objects to module.rules in lib/utils/automated-tests/getwebpackconfig.js:

{
  test: /\.js$/,
  type: 'javascript/auto',
},
{
  test: /\.js$/,
  resolve: {
    fullySpecified: false,
  }
}

Unfortunately, this doesn't solve all problems in automated testing - webpack will throw a bunch of errors that it can't find node-specific modules (e.g. Can't resolve 'stream'). More research is needed to resolve this issue.

Alternatively, we could rename all tests to .ts, as TypeScript files don't seem to suffer from this problem, but this could introduce a bunch of other issues.

For now, the easier way would probably be to add "type": "module" to package.json during the release process. If we go that route, we need to check if we also need to add "exports" to package.json to access files other than the main entry points (for example, to access the src and theme folders or package.json).

@Witoso
Copy link
Member

Witoso commented May 19, 2023

@pomek what do you think?

@filipsobol
Copy link
Member

The errors with node-specific modules might actually be caused by the setup of my local environment. I'll test this further next week, as the steps above may be enough to get it working.

@filipsobol filipsobol added the status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. label May 22, 2023
@filipsobol filipsobol self-assigned this May 22, 2023
@filipsobol filipsobol removed the pending:feedback This issue is blocked by necessary feedback. label May 22, 2023
@CKEditorBot CKEditorBot added status:planned Set automatically when an issue lands in the "Sprint backlog" column. We will be working on it soon. status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. and removed status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. status:planned Set automatically when an issue lands in the "Sprint backlog" column. We will be working on it soon. labels May 23, 2023
@filipsobol
Copy link
Member

I prepared two PRs:

TypeScript files don't need file extensions in import paths because we use "module":"es6" instead of "module":"node2016" in tsconfig.json.

I'd consider releasing alpha/beta/nightly/whatever so folks using Vite can test it. This will help us make sure we don't break anything for 39.0.0. Any thoughts? @Witoso @pomek

@pomek
Copy link
Member Author

pomek commented May 23, 2023

Changes in cke5-dev need tests not to break things in the future.

@filipsobol
Copy link
Member

Changes in cke5-dev need tests not to break things in the future.

Done ✔️

@lslowikowska lslowikowska added the support:2 An issue reported by a commercially licensed client. label Jun 15, 2023
pomek added a commit to ckeditor/ckeditor5-dev that referenced this issue Jun 29, 2023
Other (tests): A file extension is not required when resolving modules within a package marked as `type: module`. See ckeditor/ckeditor5#13673.
pomek added a commit to ckeditor/ckeditor5-linters-config that referenced this issue Dec 14, 2023
…-extensions-in-imports

Feature (eslint-plugin-ckeditor5-rules): Added a rule requiring file extensions in imports. See ckeditor/ckeditor5#13673.
pomek added a commit that referenced this issue Dec 14, 2023
…-for-import-file-extensions-2

Docs: Explain the eslint rule requiring file extensions in imports. See #13673.
pomek added a commit to ckeditor/ckeditor5-dev that referenced this issue Dec 14, 2023
Fix (tests): Fixed processing of the ESM packages when running automated and manual tests. See ckeditor/ckeditor5#13673.

MINOR BREAKING CHANGE (utils): Removed `getJavaScriptWithoutImportExtensions()` loader introduced in #885.
@filipsobol filipsobol reopened this Dec 14, 2023
@CKEditorBot CKEditorBot added this to the iteration 70 milestone Dec 14, 2023
@filipsobol filipsobol reopened this Dec 15, 2023
psmyrek added a commit to ckeditor/ckeditor5-linters-config that referenced this issue Dec 15, 2023
…-extensions-in-exports

Other (eslint-plugin-ckeditor5-rules): Improved the `ckeditor5-rules/require-file-extensions-in-imports` to require a file extension in both imports and exports. See ckeditor/ckeditor5#13673.
@filipsobol filipsobol reopened this Dec 15, 2023
filipsobol added a commit that referenced this issue Dec 15, 2023
…es-valid-esm

Fix: Make all ckeditor packages valid ES Modules. Related to #13673.
@filipsobol filipsobol reopened this Dec 15, 2023
@filipsobol
Copy link
Member

filipsobol commented Dec 15, 2023

Changes to make our packages valid ESM are merged and will be released in January.

Next week I will test our nightly releases in Vite and Vitest.

@filipsobol
Copy link
Member

The nightly releases seem to be working fine and be a valid ESM package.

arethetypeswrong.github.io:

Before: @ckeditor/[email protected]
After: @ckeditor/[email protected] (the warning about CJS is expected, because we only ship ESM)

publint.dev:

Before: @ckeditor/[email protected]
After: @ckeditor/[email protected]

@charlttsie
Copy link
Contributor

Together with @kubaklatt, we've finished testing the nightly packages in a webpack-based setup. We tested both open-source and commercial plugins. Building editors went smoothly and we haven't encountered any issues when building with the nightly packages specifically.

I've also run CKE5 E2E tests using nightly plugin versions and no issues have been found there 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:integration-dx This issue reports a problem with the developer experience when integrating CKEditor into a system. squad:core Issue to be handled by the Core team. support:2 An issue reported by a commercially licensed client. type:question This issue asks a question (how to...).
Projects
None yet
8 participants