wip: build: publish also for module ESM with new libESM #16470

karliatto · 2025-01-20T10:47:13Z

Description

Adding source to the release NPM packaged. This is common nowadays so users of the packages can transpile it as they need. It also allow them to do tree shaking.

Related Issue

Resolve #16245

mroz22 · 2025-01-20T10:50:35Z

packages/crypto-utils/package.json

@@ -22,7 +22,8 @@
    "files": [
        "lib/",
        "CHANGELOG.md",
-        "!**/*.map"
+        "!**/*.map",
+        "src/"


"files" field doesn't always contain the same lines. Do we have the ambition to unify it now across all the published packages?

That is a good question. Yes I think this is a good opportunity for doing that. Let's add "!**/*.map" and "CHANGELOG.md" ?

changelog sounds good (btw isn't it included implicitly regardless of this files field)?
about the .map file I don't have any strong opinion but it is probably better to unify it

You are right. It looks like 'yarn npm publish' includes CHANGELOG.md even if not included in "files":[..] in package.json. It is the same for README.md, but I realized in some packages we do not even have a README.md in the package. Like: https://www.npmjs.com/package/@trezor/blockchain-link-types

I think we should add at least a little README with the name and short description of the package, for the packages that we publish they probably deserve that minimum presentation.

In order to be consistent we either can add CHANGELOG.md and README.md to the "files":[..] section in package.json or remove it from all of them and the effect will be the same since yarn npm publish will publish them anyway unless we include the files in .npmignore.

@mroz22 Any opinions regarding this? Adding CHANGELOG.md and README.md to the "files":[..] section in all the publish packages or remove it?

I like the idea of being explicit more so I would add something like "*.md", to the "files":[..] section.

In order to be consistent...

yes, I don't have any strong opinion here on whether to rely on the default or list everything explicitly

I like the idea of being explicit more so I would add something like "*.md",

I wouldn't use any wildcards for md files, this could include stuff we don't actually want there.

, but I realized in some packages we do not even have a README.md in the package

good catch, lets please add them 🙏

mroz22 · 2025-01-20T10:55:54Z

doesn't it need more changes in package json? some standardized instructions for bundlers where they should look? On the other hand, a src folder in the root feels quite standard already 🤔 just brainstorming

edit: for example stuff like this https://stackoverflow.com/questions/42708484/what-is-the-module-package-json-field-for

karliatto · 2025-01-24T09:39:43Z

doesn't it need more changes in package json? some standardized instructions for bundlers where they should look? On the other hand, a src folder in the root feels quite standard already 🤔 just brainstorming

edit: for example stuff like this https://stackoverflow.com/questions/42708484/what-is-the-module-package-json-field-for

Yes, that is if we want to build packages for different modules, maybe for some packages where that makes sense we should do it. I mean for packages that are subject of being used in diverse environments.

mroz22 · 2025-01-27T16:07:51Z

I still fail to see what benefit it brings to our users to only have src added to the releases. 🤔 going through the node_moduels in our repo I can't see many src files with .ts files. Lets make one step back - what problem are we actually trying to solve by this?

Nodonisko · 2025-01-29T10:06:04Z

packages/connect-plugin-ethereum/package.json

-        "build:lib": "yarn g:rimraf ./lib && yarn g:tsc --build tsconfig.lib.json && ../../scripts/replace-imports.sh ./lib"
+        "build:lib": "yarn g:rimraf ./lib && yarn g:tsc --build tsconfig.lib.json && ../../scripts/replace-imports.sh ./lib",
+        "build:lib:cjs": "yarn g:rimraf ./lib && yarn g:tsc --build tsconfig.lib.json && ../../scripts/replace-imports.sh ./lib",
+        "build:lib:esm": "yarn g:rimraf ./libESM && yarn g:tsc --build tsconfig.libESM.json && ../../scripts/replace-imports.sh ./lib"


You will need to update replace-imports.sh scripts to update imports also in new folder and imports will be in ESM format so you will have to change regexp in file too

Yes, what about this https://github.com/trezor/trezor-suite/pull/16470/files#diff-a103ae608a95489227c717243bcc41253b4a71f7b6a7e1b4fedaea4b7f7f96ad
?

I added new optional argument that will use libESM instead of lib

Then we need to have all the @trezor/... packages that we consume to produce the libESM.

Nodonisko · 2025-01-29T10:09:49Z

scripts/updateProjectReferences.ts

@@ -144,5 +144,37 @@ import { getPrettierConfig } from './utils/getPrettierConfig';
                    process.exit(1);
                }
            }
+
+            // Copy references also to tsconfig.libESM.json if exists


You shoudn't need this, just extend tsconfig.lib.json in root tsconfig.libESM.json instead of base file

Ok, so it sounds like a good idea. Do you mean extending the tsconfig.lib.json from the package and just changing the module and outDir like here https://github.com/trezor/trezor-suite/pull/16470/files#diff-97fc10c343bde083841616cc3853cf0d7e98003d6a1b11aa36a7665e69678b0b ?

Nodonisko · 2025-01-29T10:13:14Z

packages/connect-plugin-ethereum/package.json

@@ -18,13 +18,14 @@
        "Ethereum"
    ],
    "sideEffects": false,
-    "publishConfig": {


I am not sure if we want to delete this, in case someones bundler doesn't support exports field, it will pick main: "src/index.ts" which doesn't exists in published package

I am not sure either but it sounds like good idea to keep both approaches. Seams there should not be problem with that.

Nodonisko · 2025-01-29T10:14:06Z

packages/connect-plugin-ethereum/package.json

    "main": "src/index.ts",
    "files": [
        "lib/"
    ],
+    "exports": {
+        "node": "./lib/index.js",


node sure about syntax but I think there is something like "commonjs": "./lib/index.js" which may be better

Yes, I am still polishing it. Getting some inspirations from https://nodejs.org/api/packages.html#package-entry-points

Nodonisko · 2025-01-29T10:23:04Z

.gitignore

@@ -49,6 +49,7 @@ playwright-report
 # build outputs
 lib
 libDev
+libESM


Please check also other "ignore" files in monorepo root, there are many of them

Right, updated ee0fb8c

socket-security · 2025-01-30T12:28:11Z

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert	Package	Note	Source	CI
Deprecated	npm/@types/[email protected]	Reason: This is a stub types definition. tiny-secp256k1 provides its own type definitions, so you do not need this installed.	`packages/blockchain-link-types/package.json` `yarn.lock`	🚫
Wildcard dependency	npm/@types/[email protected]	Location: Package overview	`packages/blockchain-link-types/package.json` `yarn.lock`	🚫

View full report↗︎

Next steps

What is a deprecated package?

The maintainer of the package marked it as deprecated. This could indicate that a single version should not be used, or that the package is no longer maintained and any new vulnerabilities will not be fixed.

Research the state of the package and determine if there are non-deprecated versions that can be used, or if it should be replaced with a new, supported solution.

What are wildcard dependencies?

Package has a dependency with a floating version range. This can cause issues if the dependency publishes a new major version.

Packages should specify properly semver ranges to avoid version conflicts.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all

@SocketSecurity ignore npm/@types/[email protected]

github-actions · 2025-01-30T12:28:58Z

🚀 Expo preview is ready!

Project → trezor-suite-preview
Platforms → android, ios
Scheme → trezorsuitelite
Runtime Version → 24
More info

Learn more about 𝝠 Expo Github Action

karliatto requested review from martykan, szymonlesisz, mroz22, marekrjpolak and tomasklim as code owners January 20, 2025 10:47

mroz22 reviewed Jan 20, 2025

View reviewed changes

karliatto force-pushed the chore/add-src-to-release branch from 1387664 to 8c2e6aa Compare January 24, 2025 08:31

karliatto force-pushed the chore/add-src-to-release branch from 8c2e6aa to 94d7010 Compare January 28, 2025 15:57

karliatto requested a review from Nodonisko as a code owner January 28, 2025 15:57

Nodonisko reviewed Jan 29, 2025

View reviewed changes

karliatto changed the title ~~Chore: add src to release~~ wip: chore: add src to release Jan 30, 2025

karliatto added 6 commits January 30, 2025 09:56

chore(blockchain-link-utils): add README.md

7488186

chore(connect-plugin-ethereum): add libESM configurations

d7f5f00

chore(connect-plugin-stellar): add libESM configurations

617fe86

chore(env-utils): add README.md

a9125c7

chore(blockchain-link-types): add README

d02f4e7

chore: add new libESM configuration

ee0fb8c

karliatto force-pushed the chore/add-src-to-release branch from 819288e to ee0fb8c Compare January 30, 2025 09:57

karliatto changed the title ~~wip: chore: add src to release~~ wip: build: new libESM in each published package Jan 30, 2025

wip

f84da11

karliatto changed the title ~~wip: build: new libESM in each published package~~ wip: build: publish also for module ESM with new libESM Jan 30, 2025

wip

0bb8881

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wip: build: publish also for module ESM with new libESM #16470

wip: build: publish also for module ESM with new libESM #16470

karliatto commented Jan 20, 2025

mroz22 Jan 20, 2025

karliatto Jan 20, 2025

mroz22 Jan 20, 2025

karliatto Jan 24, 2025

karliatto Jan 24, 2025

karliatto Jan 24, 2025

mroz22 Jan 27, 2025

mroz22 commented Jan 20, 2025 •

edited

Loading

karliatto commented Jan 24, 2025

mroz22 commented Jan 27, 2025

Nodonisko Jan 29, 2025

karliatto Jan 30, 2025

karliatto Jan 30, 2025

Nodonisko Jan 29, 2025

karliatto Jan 30, 2025 •

edited

Loading

Nodonisko Jan 29, 2025

karliatto Jan 30, 2025

Nodonisko Jan 29, 2025

karliatto Jan 30, 2025

Nodonisko Jan 29, 2025 •

edited

Loading

karliatto Jan 30, 2025

socket-security bot commented Jan 30, 2025

github-actions bot commented Jan 30, 2025

wip: build: publish also for module ESM with new libESM #16470

Are you sure you want to change the base?

wip: build: publish also for module ESM with new libESM #16470

Conversation

karliatto commented Jan 20, 2025

Description

Related Issue

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mroz22 commented Jan 20, 2025 • edited Loading

karliatto commented Jan 24, 2025

mroz22 commented Jan 27, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karliatto Jan 30, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nodonisko Jan 29, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

socket-security bot commented Jan 30, 2025

Next steps

github-actions bot commented Jan 30, 2025

mroz22 commented Jan 20, 2025 •

edited

Loading

karliatto Jan 30, 2025 •

edited

Loading

Nodonisko Jan 29, 2025 •

edited

Loading