-
Notifications
You must be signed in to change notification settings - Fork 580
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
CommonJS bundle (without Rollup) #5853
Conversation
Woups - looks like I need to find a solution for re-enabling test coverage 🤔 |
5791bad
to
0b3f9ea
Compare
packages/realm/package.json
Outdated
"react-native": "./generated/native-react-native.mjs" | ||
}, | ||
"./binding/core": "./dist/generated/core.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.
Can the core
part be moved into the other ".binding"
block?
"react-native": "./generated/native-react-native.mjs" | |
}, | |
"./binding/core": "./dist/generated/core.js", | |
"react-native": "./generated/native-react-native.mjs", | |
"core": "./dist/generated/core.js" | |
}, |
.gitignore
Outdated
/packages/realm/generated/ | ||
/packages/realm/src/generated/ |
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 silly to have two separate generated directories here. Can they be combined?
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 needed to move core.ts
into src
when adopting TypeScript projects, because of:
error TS6059: File '/Users/kraen.hansen/Projects/realm-js/packages/realm/generated/core.ts' is not under 'rootDir' '/Users/kraen.hansen/Projects/realm-js/packages/realm/src'. 'rootDir' is expected to contain all source files.
The file is in the program because:
Matched by include pattern '../generated/core.ts' in '/Users/kraen.hansen/Projects/realm-js/packages/realm/src/tsconfig.json'
And I don't really consider the wrapper .mjs files and realm.node file as "src" as it's not TS and won't be moved to "dist" by tsc. Adding to that, I don't know yet if we actually want to add the src
files to the archive that we upload to NPM (lots of packages don't - most likely to keep their size and complexity low).
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.
Hmm. I'm not sure we have a clear rule for what src/
is. Is it where we put the "source code" for the realm package, or is it only the input for tsc
? I had assumed the former, but it seems like you intend for it to be the later. I guess I don't feel too strongly either way, but we should be clear what our rule is.
@@ -125,7 +125,7 @@ file(GLOB_RECURSE SDK_TS_FILES | |||
list(FILTER SDK_TS_FILES EXCLUDE REGEX "templates/[^/]*\.ts$") | |||
|
|||
set(JS_SPEC_FILE ${SDK_DIR}/bindgen/js_spec.yml) | |||
set(TYPESCRIPT_OUTPUT_DIR ${SDK_DIR}/generated/ts) | |||
set(TYPESCRIPT_OUTPUT_DIR ${SDK_DIR}/generated) |
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.
Shouldn't this be src/generated
?
@@ -1433,6 +1437,7 @@ export declare namespace Realm { | |||
CollectionChangeSet, | |||
/** @deprecated Please use named imports */ | |||
CollectionType as Collection, | |||
CompensatingWriteErrorType, |
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.
CompensatingWriteErrorType, | |
CompensatingWriteErrorType as CompensatingWriteError, |
"types": ["node"], | ||
"noResolve": false, | ||
"incremental": true, |
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.
Do we want to remove incremental here? It does seem to speed up incremental building.
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.
As I understand it (and as I can see tsbuildinfo files on disk), it's default for a composite
config.
It's not explicit from the documentation though: https://www.typescriptlang.org/docs/handbook/project-references.html
packages/realm/src/cjs.ts
Outdated
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 is with mixing the index.cjs.ts
and cjs.ts
naming conventions? Can we pick one. Also do we need both index.cjs.ts and index.ts? or could they be combined?
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.
do we need both index.cjs.ts and index.ts? or could they be combined?
I wanted the ensure the general code-base was ESM and the cjs.ts
was only to export an entrypoint for the types. I'll align the naming though 👍
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.
(FYI in markdown you need a blank line after the last quoted line in order to end a quote and start your reply)
I wanted the ensure the general code-base was ESM and the cjs.ts was only to export an entrypoint for the types. I'll align the naming though
We still could get rid of index.ts and move its minimal contents to index.cjs.ts. It just seems weird to have both with the same root name. If you really want to keep as much as possible out of cjs files, it may be best to rename index.ts to reexport.ts or umbrella.ts.
${GENERATED_OUTPUT_DIR}/native.d.mts | ||
${TYPESCRIPT_OUTPUT_DIR}/core.ts |
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 see how that can be right. These are build by the same command and it is only told about the path to TYPESCRIPT_OUTPUT_DIR
.
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.
True - I was missing a replace here 👍
OUTPUTS ${GENERATED_JS_FILES} | ||
OUTDIR ${TYPESCRIPT_OUTPUT_DIR} | ||
OUTDIR ${GENERATED_OUTPUT_DIR} |
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 think you meant to change lines 144/145 instead. Right now there are out of sync.
4ca8407
to
d83f22a
Compare
Drafting this as it's been superseded by #5882 .. I might close when I accept my defeat and feel better about the time I've already sunk into this. |
I'm guessing we are going to close this, or? |
@takameyer see my previous comment 🙂 |
Closing this as I've created #5894 to eventually do this migration. |
What, How & Why?
This fixed #5857 by removing rollup from the SDK package in favour of a TypeScript projects based setup which emits only CommonJS code.
This is aligned with recent discussions on the team to ensure v12.0.0 exports exactly as v11 did, to keep friction from migrating at an absolute minimum.
I ran into several problems of which some I managed to find workarounds for and others I didn't:
.mjs
files even whenmodule
was set tocommonjs
which would break the package upon import. I filed an issue for this, created a PR and found a temporary workaround.bundleDependencies
to pull @realm/network-transport (and a new@realm/binding
package) into the SDK's .tar.gz before uploading it to NPM. But this is not supported when using NPM workspaces (yet) :meow_sad: [BUG] Workspaces - bundledDependencies missing in tarball after npm pack npm/cli#3466