-
Notifications
You must be signed in to change notification settings - Fork 3
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
Libs tidy up part 5 - Move core to lib #1734
base: main
Are you sure you want to change the base?
Conversation
|
Ad load time test resultsFor Test conditions:
|
We still have the 2 parts, bundle and the core/libs used by other projects, do we not want to keep them seperate in some way? |
🚀 To install the beta version, run one of the following commands in your project directory:
|
I don't see the need for the distinction any more - its just libs? We have some lib functions which we use internally and also export e.g. Is there any advantage to splitting 'core' and the rest of the codebase? |
If merged, it may be hard to distinguish if a change will affect an exported module and thus require a changeset and version bump. I also just like the mental distinction, they feel live quite separate things to me, maybe we can see what others think? |
Thanks core vs libI can see it helps to separate the idea of 'core' but I think my main point is that its hard to define the line between core and the rest of the codebase. I suspect the confusion would remain as core modules also depend on the main 'lib' so its hard to know if any updates affect the call chain that ends up in 'core' changing. So to have a clear idea of what can affect core would mean pulling the complete dependency chain into core. Also its a side point but core is quite a mixed bag, there are modules in there that are not exported - e.g. messenger, third-party-tags. There are duplicate libs e.g. geolocation and url parsing which is hard to see without consolidation. changesetsI've tended to use changesets to indicate breaking, minor, patch of the bundle and core, rather than just being specific to core, for example when upgrading prebid. The riff-raff deploy changes the visibility of the version but its still useful to understand the implication of a change to bundle. Would be good to get other opinions! |
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.
LGTM - does the renaming and reorganising as described in the PR description. Though I'm not very familiar with the commercial code yet so can't review from a more specific angle!
EDIT: I've just read the other comments on this PR, sorry for jumping the gun with my review before. I think since I haven't used commercial in practice I'm not the best person to approve this!
"scripts": { | ||
"build": "npm-run-all clean --parallel compile:core:* build:prod build:dev build:riff-raff", | ||
"build:dev": "webpack -c webpack.config.dev.mjs", | ||
"build:prod": "webpack -c webpack.config.prod.mjs", | ||
"build:riff-raff": "webpack -c webpack.config.riff-raff.mjs", | ||
"clean": "rm -rf dist", | ||
"compile:core:common": "tsc --project ./tsconfig.core.json --outDir ./dist/cjs --module CommonJS", | ||
"compile:core:esm": "tsc --project ./tsconfig.core.json --outDir ./dist/esm", | ||
"compile:core:common": "tsc --project ./tsconfig.core.json --outDir ./dist/core/cjs --module CommonJS", |
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.
Is common still used? Since the filepath for main
on L17 has been updated from cjs to esm
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.
Oops! Thanks good spot
I don't think the cjs build is used by any clients of commercial (Frontend or DCR). Removing it is on my todo list but will do separately to keep this PR focussed.
Opening up the floor to other commercial developers
Just weighing in on the separation of core vs lib. I'm personally in favour of merging them. I regularly get a bit frustrated when working with things like page targeting, and having to look at files in core and in lib. The separation can make it harder for me to find the file I need. I do understand the point around making it clear what changes would result in a bump to 'core' in DCR. However, I guess we can't say for sure that commercial will still be used in exactly the same way as it is now a year or two down the line. I agree that it makes sense for us to keep using changesets for all changes, even if they're not in 'core'. I think that futureproofs us a little better as well as keeps our changes nice and transparent! |
Okay I'm convinced! Thanks for weighing in everyone :) |
🚀 To install the beta version, run one of the following commands in your project directory:
|
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 checked the PR comments and I definitely need to understand a bit more about how core and lib are being used and then I will be able to give my opinion on it. I will make sure to put some time tomorrow to clear my understanding. If I have any questions will post it on the chat.
What does this change?
Following #1729 we now have two main locations for lib type modules:
This PR moves all
core
modules tolib
and also creates a top levelexport.ts
which exports all the functions required by clients of the commercial library.- core
- lib
- lib
- lib
export.ts
The dist output has also been updated:
- dist
- esm
- core
- dist
- core
- esm
Why?
Consolidate all libs and utils to one part of the codebase