-
Notifications
You must be signed in to change notification settings - Fork 7
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
Rewrite in TypeScript (WIP) #10
Rewrite in TypeScript (WIP) #10
Conversation
@scottrobertson should I go ahead and setup eslint and/or prettier? EDIT: Never mind. That would be completely out of scope for this PR |
@sduduzog will this introduce any breaking changes at all with Vue2, Vue3 or Nuxt/Vue2? |
It should not. In fact, it should be exactly as it was with valilla javascript. I do however hope to give this PR more love. I still want to check if there are parts of it that could be done better, i.e. a production example library that took similar or alternative routes that I could learn from. After that, I will need your help with testing a release, something like an alpha or beta idk. Just to make sure that the package.json changes to file routing after publishing still resolve correctly. |
Awesome :) let me know if there is anything I can do. |
@scottrobertson It turns out, the workflow build step might not be required at all, with the prepare script added to package.json, the code is built automatically. This also means I have to rename this PR to reflect what is actually going on |
This reverts commit 9166bb5.
Here's where I need help @scottrobertson Could you please create a release just so that we test out the package is being packaged properly.
What I noticed with testing though is that when using yarn with vite, not all the bundles are created. The types file is not outputed and the esm file is also not outputed which shouldn't be the case. This is why we need a test release, to see if these files are packed when a release is published. There's a high chance that this was an anomaly with my own project but rather be safe than sorry later. |
Can do :) away today but I will sort it tomorrow morning. |
Also, I think you should do the npm release manually..., as to not create a tag on github as when a workflow is in use... I"m not sure too with this one but seems cleaner |
|
@scottrobertson Thank you. I'll test it out but I'm not happy with yarn complaining when I'm installing this from github. I fear it might be some sneaky bug hiding somewhere within the setup or I'm doing something wrong. I still need more information before I'm comfortable with this PR |
Actually it fails even installed from npm... I'll work on that now. @scottrobertson |
There's a high chance that my issue was caused by the fact that I didn't have a One more favour, Could you please create another beta release when you can @scottrobertson |
|
Thanks for these releases, I'll remove the WIP when I've tested across multiple project types:
|
@scottrobertson I finally got time to test this with my projects. We're all good to go. Anything coming our way I'll be on hand to tackle |
Thank you @sduduzog Want me to trigger a release? |
Yes |
What kind of change does this PR introduce?
What is the current behavior?
What is the new behavior?
users can now do:
Additional context
Previously, the plugin worked without any build step and with the change in file structure along with the package.json, it's important to test first that the npm release works as intended, that correct files are exposed and that they are resolved correctly.
It was previously easy to pretest PRs by installing a package from a github branch directly.
Given that the above tests pass, this PR will be ready but also, it's worth investigating if it's possible to build files on "postinstall" hook by npm
EDIT
Turns out the build step is not required.
There's an npm hook that is called before the package is published and also called after the user runs
npm install
oryarn install
This is where we build our typescript to create multiple bundles.