-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat!: publish as esm-only #56
Conversation
Following on from the conversation in ipld/ipld#224 this converts this repo to use the latest aegir with Unified CI. 1. Remove all dev deps apart from `aegir` 1. Run the `npx aegir check-project` command to update project config 1. Remove non-Unified-CI github actions 1. Update imports to import from `src/index.js` instead of `@ipld/dag-pb` 1. Rename `test/*.js` to `test/*.spec.js` so aegir can find them 1. Update `tsconfig.json` to extend config from `aegir` 1. Remove `"main"` and other unused fields from `package.json` 1. Use `chai` from `aegir` pre-configured with plugins we use This will need a follow up PR to `protocol/.github` to add this repo to the Unified CI [config file](https://github.com/protocol/.github/blob/master/configs/js.json) so it'll get automated config updates in the future. Apologies that this PR is so noisy, most of it is from the `check-project` command
@@ -1,16 +1,11 @@ | |||
version: 2 | |||
updates: | |||
- package-ecosystem: 'github-actions' |
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.
I don't know if we want to reinstate this, probably not - the view of the stewards seems to be to not pull in arbitrary github actions versions, instead to lock them down to individual commits managed by Unified CI, apart from a few blessed actions (essentially only the ones published by github).
"build": "aegir build", | ||
"release": "aegir release", | ||
"test": "aegir test -t node -t browser -t webworker -t electron-main", | ||
"test:ts": "npm run test --prefix test/ts-use", |
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.
I wasn't sure what to do with this, since we don't test ts integration like this in libp2p/ipfs anywhere else (yet).
Just tagged it on to the end of - if it's useful we can add a block to the test:node
for nowjs-test-and-release.yml
action? Might be preferable.
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.
It seems the test command in ts-use
uses an argument format that means it doesn't work on Windows.
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.
Having the TS tests be par of js-test-and-release.yml
would be great. I'm not sure how they should be approached yet though.
Would running the tests as TS but having the TS tests import JS tests work?
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.
It's worth a shot, though the tests are compiled to js before execution so my brain turns inside out a little bit.
|
||
An implementation of the [DAG-PB spec](https://github.com/ipld/specs/blob/master/block-layer/codecs/dag-pb.md) for JavaScript designed for use with [multiformats](https://github.com/multiformats/js-multiformats) or via the higher-level `Block` abstraction in [@ipld/block](https://github.com/ipld/js-block). |
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.
why did this get removed? does the tooling just expect the intro section to be badges?
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.
No particular reason - the readme is parsed and standardised by aegir to have the same badges, toc, license, install instructions etc everywhere.
It's a work in progress though, more than happy to merge fixes to the implementation.
"types": "./dist/src/index.d.ts", | ||
"import": "./src/index.js" |
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.
so what is the purpose of dist
? is it just meant to be the pieces that aren't checked in but are built at publish-time? i.e. the types?
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.
Might be useful to move it into the types
folder the way we have for js-miltiformats. Or is dist
the standard accross all the other IPFS repos?
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.
dist
is standard across all other IPFS repos.
is it just meant to be the pieces that aren't checked in but are built at publish-time? i.e. the types?
Exactly, yes - types, minified bundles, source maps, all that stuff.
import { bytes } from 'multiformats' | ||
import { CID } from 'multiformats/cid' | ||
import { encode, decode } from '@ipld/dag-pb' |
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.
what breaks for this to need to change? we could add back "paths"
if it's typescript compiling that's failing; it's kind of nice to be consuming it as an external consumer would
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.
Honestly this paths thing is super complicated and I don't see other projects doing it that way. 😅
I think it's related to some of the issues we're seeing with duplicate multiformats causing errors.
From what I'm seeing, the paths
thing is counter to how ESM works and doesn't play nice with esbuild.
I think the ts-use
pattern could be useful for making sure it works as a consumer.
@achingbrain Do you think you'd have time to review Rod's latest changes in the v10.0.0 branch of multiformats to see if there's stuff in there that should be ported here? |
We may wish to roll #59 into this but it's blocked by multiformats/js-multiformats#208 (fixed by multiformats/js-multiformats#210) |
👍 this all looks good to me, minus the multiformats@10 problems; I wouldn't mind confirming for myself that the types are going out to the place identified by the package.json, it looks all right but we keep on having problems with type exports! |
how about we just switch to |
Seems reasonable in places where we just compare two CIDs, but it won't work in places where we do deep equality checks on objects with CID fields without pulling those fields out or overwriting them. |
multiformats/js-multiformats#215 makes the tests in this PR pass for me |
Not this PR, I mean rolling |
## [3.0.0](v2.1.18...v3.0.0) (2022-10-19) ### ⚠ BREAKING CHANGES * publish as esm-only (#56) ### Features * publish as esm-only ([#56](#56)) ([27e1076](27e1076)) ### Trivial Changes * **no-release:** bump @types/mocha from 9.1.1 to 10.0.0 ([#58](#58)) ([6475261](6475261)) * **no-release:** bump actions/setup-node from 3.4.1 to 3.5.0 ([#57](#57)) ([72521b4](72521b4)) * **no-release:** bump actions/setup-node from 3.5.0 to 3.5.1 ([#60](#60)) ([eaa7039](eaa7039))
🎉 This PR is included in version 3.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Following on from the conversation in ipld/ipld#224 this converts this repo to use the latest aegir with Unified CI.
aegir
npx aegir check-project
command to update project configsrc/index.js
instead of@ipld/dag-pb
test/*.js
totest/*.spec.js
so aegir can find themtsconfig.json
to extend config fromaegir
"main"
and other unused fields frompackage.json
chai
fromaegir
pre-configured with plugins we useThis will need a follow up PR to
protocol/.github
to add this repo to the Unified CI config file so it'll get automated config updates in the future.Apologies that this PR is so noisy, most of it is from the
check-project
command