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

feat!: publish as esm-only #56

Merged
merged 6 commits into from
Oct 19, 2022
Merged

feat!: publish as esm-only #56

merged 6 commits into from
Oct 19, 2022

Conversation

achingbrain
Copy link
Member

@achingbrain achingbrain commented Aug 30, 2022

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
  2. Run the npx aegir check-project command to update project config
  3. Remove non-Unified-CI github actions
  4. Update imports to import from src/index.js instead of @ipld/dag-pb
  5. Rename test/*.js to test/*.spec.js so aegir can find them
  6. Update tsconfig.json to extend config from aegir
  7. Remove "main" and other unused fields from package.json
  8. Use chai from aegir pre-configured with plugins we use
  9. Fixes everything the linter complains about

This 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

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'
Copy link
Member Author

@achingbrain achingbrain Aug 30, 2022

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",
Copy link
Member Author

@achingbrain achingbrain Aug 30, 2022

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 test:node for now - if it's useful we can add a block to the js-test-and-release.yml action? Might be preferable.

Copy link
Member Author

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.

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?

Copy link
Member Author

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).
Copy link
Member

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?

Copy link
Member Author

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.

Comment on lines +50 to +51
"types": "./dist/src/index.d.ts",
"import": "./src/index.js"
Copy link
Member

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?

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?

Copy link
Member Author

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'
Copy link
Member

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

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.

@RangerMauve
Copy link

@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?

@achingbrain
Copy link
Member Author

We may wish to roll #59 into this but it's blocked by multiformats/js-multiformats#208 (fixed by multiformats/js-multiformats#210)

@rvagg
Copy link
Member

rvagg commented Oct 17, 2022

👍 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!

@rvagg
Copy link
Member

rvagg commented Oct 17, 2022

how about we just switch to cid1.equals(cid2) or cid1.toString() === cid2.toString() here for now to get over that particular hump and get this unblocked for a release?

@achingbrain
Copy link
Member Author

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.

@achingbrain
Copy link
Member Author

multiformats/js-multiformats#215 makes the tests in this PR pass for me

@achingbrain
Copy link
Member Author

Not this PR, I mean rolling multiformats@10.x.x into this PR.

@achingbrain achingbrain marked this pull request as ready for review October 18, 2022 06:38
@achingbrain achingbrain merged commit 27e1076 into master Oct 19, 2022
@achingbrain achingbrain deleted the feat/publish-as-esm-only branch October 19, 2022 09:50
github-actions bot pushed a commit that referenced this pull request Oct 19, 2022
## [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))
@github-actions
Copy link

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 🎉 Done
Development

Successfully merging this pull request may close these issues.

3 participants