-
Notifications
You must be signed in to change notification settings - Fork 55
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
Dependency Updates #246
Dependency Updates #246
Conversation
Migrate off of the old rc/json config standard to the new flat file config format. All settings have been retained from before. The node-modules directory doesn't have to be explicitly called out since it is ignored by ESLint by default.
Update the ignore file to the latest spec provided by GitHub: https://github.com/github/gitignore/blob/main/Node.gitignore
Re initialize the project so that all of the new configurations are present. All of the same settings are present with the addition of the new defaults in the latest TS configs.
Since Node 18 LTS is the earliest supported version of Node.JS, match the TS output with the maximum version of ECMAscript that is supported by Node.JS 18 LTS. Disable declaration source maps since the source maps are already included with the project. Disable downlevel iteration since ES2022 is the target and it supports modern iteration. This will improve performance. Remove comments from the transpiled output since they aren't necessary in production, this will reduce bundle size of the final project. Since the target is now ES2022, the lib config is not needed since the functionality is now included in the language output.
Remove the cross-env command since it was un-used. The cross-env package is also depricated. The Node_environment should be set externally, not inline with the test script. Additionally, it wasn't even used in this project...
Since no JS exists any more, this is failing test runs.
Since the JSON files don't get included in the compiled output. Additionally, the TS Config file is supposed to follow the official TS specification, not the custom standard we are currently using. The one we use reduces readability compared to the default config.
@rhys-vdw, I honestly don't know how to fix the latest failing test. Everything except that one test passes, and I can't seem to track down where the generated file shows up and what is expected of it to verify the content is expected. Would you be able to assist me with this? |
Update the NPM ignore to support the new flat file ES Lint config.
Replace the prepare script with a new production build optimized build command that doesn't emit sourceMap files. This reduces bundle size at publish time.
Reduce command chaining by splitting the respective pre-execution commands into a "pre" script in the script lifecycle manager. https://docs.npmjs.com/cli/v10/using-npm/scripts#pre--post-scripts
Ah yeah, that test is hardcoded to a specific output from UglifyJS, which you probably updated. The purpose of the test is to ensure that the shortcircuit function will result on code stripping (as per thereadme). Really the check is to make sure the body of the function was stripped due to a constant expression being evaluated as false. Maybe we could change it to check for the lack of presence of a variable name in the output so it's less brittle. |
the --ext param is no longer available. The target files are not configured in the linter config itself.
Updated the expected output for the new ES2022 output compatibility that Node 18 brings. The updated ES2022 logic is related to the module system.
Nice one. In a recent project I discovered that you can greatly simplify tsconfig by using the
Do these have any value? I don't recall deliberately enabling their generation.
I have enabled it for this repo now, but only after the tests ran. I'm not sure I can trivially re-run it for this PR. Otherwise looks great, thanks for doing this drudgework of bringing the project up to speed. Feel free to make other improvements as required, but for anything major I'd prefer an issue were opened for discussion first. I'm happy to merge this one but I'll let you do the honours. I'll get a notification and can run the release script when it's done. |
I am interested in doing further cleaning, I was thinking of migrating the test system to something more mainstream, like Mocha, it will improve the readability of the tests a ton. I was also thinking about moving everything out of just a single file and into a file/folder structure.
Only for a certain type of debugging that I don't expect us to do on our side. I am prepping a new PR for deep VS code integration which actually uses the map files but only the I am not aware of anything that you are currently doing that would require them, they 100% aren't useful for end users since you don't ship the
Awesome! No worries on not having it here. It will just add security risk context to the PR if it finds anything. I have manually ran all of the deps through socket by hand while I was waiting.
No worries, can do :)
I prefer you to do the merges as I don't want to overstep my permissions that you have granted me. Technically I can bypass merge reviews since you made me a contributor, if this was not intentional, I can show you have to enforce branch protection policies on the project to prevent people like me from taking over the project :-P |
Oh sorry, I understood this to mean that ts-auto-guard was outputting them. Yeah, they have no use in the build process.
Ah that's fine, you don't have the ability to do a release which is the only real security concern IMO. |
Check your email on that last one. Sent you a security risk notice. |
Hey @elliot-huffman, just running the release now. https://github.com/rhys-vdw/ts-auto-guard/actions/runs/9459986476 Will reply to your email in time, bit busy atm. :-) |
Ah looks like I need to make some token updates. Will handle in time! |
Changelog
BREAKING CHANGES
d.ts.map
) are no longer generated (thed.ts
files still are though)