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

v2 release discussion #718

Closed
GrosSacASac opened this issue Mar 24, 2021 · 72 comments
Closed

v2 release discussion #718

GrosSacASac opened this issue Mar 24, 2021 · 72 comments

Comments

@GrosSacASac
Copy link
Contributor

Creating this issue to have one place to discuss the v2 release.

I think that we should clean up the changelog. By that I mean remove from the changelog everything that is noise for the average formidable user. For example >" refactor: use hasOwnProperty in check against files/fields" is not useful information for someone that is trying to migrate from v1 to v2. If you agree I can make a PR for that.

First time since a long time that we are under 30 open issues 🥇 .

Ideally we also

  • fix the tests (they broke since I migrated to Jest a bit too fast).
  • create a migration guide
@tunnckoCore
Copy link
Member

Agree. These are noise. The beginning is good. They have links to all the issues and PRs to see how much work is done.

Migration guide is nothing more than the exports change. Oh yea, and the plugins API and the cool fileWriteStream handling.

@karlhorky
Copy link

From my comment here: #635 (comment)

I guess #689 was merged and then the filter PR #716 was also merged, right? I guess that means a v2 release sometime in the next few weeks?

Is this true? Would a v2 release be sometime in the next weeks?

@karlhorky
Copy link

  • fix the tests (they broke since I migrated to Jest a bit too fast).

Which tests are broken? Everything on GitHub Actions that's failing on the master branch?

https://github.com/node-formidable/formidable/runs/2249456170

Would be good to have a clear list of open tasks and how to attack them, just in case anyone (eg. @Songkeys) would like to contribute here.

@GrosSacASac
Copy link
Contributor Author

Which tests are broken? Everything on GitHub Actions that's failing on the master branch?

Fixtures. When you try to run tests locally you can see.

Is this true? Would a v2 release be sometime in the next weeks?

Soon ™ lol

@GrosSacASac
Copy link
Contributor Author

https://ko-fi.com/tunnckoCore Everyone get in

@GrosSacASac
Copy link
Contributor Author

@tunnckoCore publish v2 whenever you are ready, I am going to start the v3 branch soon

@GrosSacASac
Copy link
Contributor Author

GrosSacASac commented Apr 21, 2021

ideally sooner than later because most people assume npm contains the last version and create issue like this #726 , #736

And on stackoverflow there are a lot of people still on v1

@fwh1990
Copy link

fwh1990 commented Apr 29, 2021

Expect to see v2 released in these days, and don't forget to upgrade @types/formidable as well.

@karlhorky
Copy link

karlhorky commented Apr 29, 2021

Yeah, @types/formidable are currently broken with the 1.2.2 version (which means they'll be also broken for v2), after the PR from @peterblazejewicz and @martin-badin :

DefinitelyTyped/DefinitelyTyped#51364 (comment)

@peterblazejewicz
Copy link

@karlhorky
We can revert the 1.2.2 changes or the conflicting change can be fixed by PR. I'd nt say types are broken.

@peterblazejewicz
Copy link

x-ref: DefinitelyTyped/DefinitelyTyped#52697

@tunnckoCore
Copy link
Member

Hey there, sorry for the silence lately! :)

I'm sorry for saying it again, but... I'm really currently upgrading the machine (ahhh, damn tired of jumping around linux distros, it was great on ArchLinux for YEARS, the thing is I don't have the nerves to restore my awesome setup ;d).

I'm in terrible period, but it's now 15 days holidays here and I'm REAAALLY heating and getting up. Еxcuses, excuses, excuses... anyway.

Thanks!

PS: Even if everything is okay on the branches, i can't just run npm publish because don't have setup here.

@karlhorky
Copy link

As of @types/[email protected], the types are working again 🙌 I guess they should also work for Formidable v2 too. 👍

Thanks to @peterblazejewicz for the fix!

DefinitelyTyped/DefinitelyTyped#52697 (comment)

@peterblazejewicz
Copy link

you're welcome! I've not been using this module a lot, so keep this in mind, when something surfaces, thx!

@GrosSacASac
Copy link
Contributor Author

To install from github master in the meantime
npm i github:node-formidable/formidable

@fwh1990
Copy link

fwh1990 commented Jun 1, 2021

To install from github master in the meantime
npm i github:node-formidable/formidable

Without correct type definition

@TheThing
Copy link

TheThing commented Jul 2, 2021

Just a heads up but the bulkiness of formidable has increased quite dramatically in the 2.x version.

Original 1.2 had zero dependency which was... very nice. The new "and improved" 2.x has quite a lot of junk dependencies:

Some of these are... quite unnecessary like once which hasn't been updated in over 5 years and is literally a few lines of code.

Not to mention dezalgo which is literally a few lines of codes with two more additional dependencies, that are also few lines of code, just to make a callback run on next tick? Feels HIGHLY overkill to have to install 3 dependencies just for a tiny functionality like that.

I know npm and javascript developers don't care about what kind of code they're installing with their library but some of us actually care. :(

According to bundlephobia, your 2.x release is 50% your code and 50% external code after installation, at least according to bundlephobia.

Update:
Can you guys guess which release is which? This is insane jump in size imo

2.x installation jumps from measly 87KB to 2.4MB

@GrosSacASac
Copy link
Contributor Author

the 3.x version already got rid of the qs dependency

For the rest you are right I agree , some could be removed, but it has to be done on a case by case basis, sometimes a 20 line of code library handles quite a few edge cases one would not necessarily think about it.

Also if you make a PR try to find out why a library is used, maybe there is a good reason.

@TheThing
Copy link

TheThing commented Jul 8, 2021

If I may ask @GrosSacASac what's the difference between 1.x and 2.x and 3.x? I'm not finding a good change log

@GrosSacASac
Copy link
Contributor Author

GrosSacASac commented Jul 9, 2021

https://github.com/node-formidable/formidable/blob/3.x/CHANGELOG.md
below version 3 is version 2
if anything is missing tell me

@pubmikeb
Copy link

pubmikeb commented Jul 9, 2021

Zero dependencies and 85.1 kB package size used to be definitely killer features of formidable comparing to multer.

Is there any roadmap when the v.2.0 will be released?

BTW, the change log for the v.3.0 looks quite decent, may be it is worth skipping the v.2.0 and merge it with v.3.0?

Regarding the version v.3.0, is there any way to install it via npm already today?
The latest canary build I can find is 2.0.0-canary.20200504.1, which looks like to be outdated (2020-05-04).
I would like to switch from the abandoned multer (no Node.js 16+ support) and formidable v.3.0 seems to be a great choice.

BTW, hopefully, the version v.3.0 comes not only in the form of the ESModule (import-from instead of require) but also with the async/await support out-of-box and will be the callbacks-free.

@GrosSacASac
Copy link
Contributor Author

v2 was supposed to be published a couple months ago already, unfortunately people with access to npm publish are absent nowadays ... Myabe you can try to tweet if you have twittter

There is an open issue for async await #685

To install 3.x with npm use

npm i node-formidable/formidable#3.x

@pubmikeb
Copy link

pubmikeb commented Jul 10, 2021

To install 3.x with npm use

npm i node-formidable/formidable#3.x

I'm trying to install it via package.json, but there I can't fin a v.3.0 as a proposed version for formidable:

10_020738

Is it possible to install v.3.0 via package.json?

Update

This should work:

"formidable": "[email protected]:node-formidable/formidable#3.x"

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

  • Added VERSION_NOTES on the master branch. Make a shortlink for that and add it on the deprecation messages.
  • Updated some badges and stuff on the master README.
  • Added the notes to v1 branch readme too, intentionally cuz it should be in front of their eyes.

and we can close this

@GrosSacASac
Copy link
Contributor Author

Ok

Ok So master is 3.x So we merge #767 now ?

Dist tags are like pointers that point to a specific version, we can only deprecate versions.

Ok I will publish

@GrosSacASac
Copy link
Contributor Author

Published 1.2.4
Published 2.0.0 as latest

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

Okay, great.

v3 is master, yea. But I don't know what is in v2 in git, what is in v2 in npm, what's the diff with v3, and what we should move from v2/master to a separate v2 branch. 🤣

But anyway, we will figure it out. Just publish v2 to v2 dist-tag too, and your v3 (#767?) to v3 dist-tag.

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

Oh and rename the dist-tags on npm, because notes mention v1, v2, v3 and not 1.x, 3.x (don't like that notation and is a bit harder). 😆 🚀

@GrosSacASac
Copy link
Contributor Author

Created a 2.x branch from master, then merged 3.x branch into master

@GrosSacASac
Copy link
Contributor Author

Should I drop "canary" ? Since we already have tags ?

@GrosSacASac
Copy link
Contributor Author

Published [email protected] in v3 tag (with your VERSION_NOTES and updated readme)

@GrosSacASac
Copy link
Contributor Author

Tried v2 tag but

Tags that can be interpreted as valid semver ranges will be rejected. For example, v1.4 cannot be used as a tag, because it is interpreted by semver as >=1.4.0 <1.5.0. See #6082.

I don't know why it worked with the v3 tag

@GrosSacASac
Copy link
Contributor Author

We could do like npm https://www.npmjs.com/package/npm latest-1 latest-2 latest-3 etc

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

duh.. 🤣 well, okay. and instead of canary we will publish to next-2 and next-3 for preview versions like they do it.

but should update all the notes first haha.. I will handle the VERSION_NOTES and v2 branch

@GrosSacASac
Copy link
Contributor Author

Should I run this command ?
npm deprecate formidable@"<2.0.0" "Please upgrade to latest formidable@latest or formidable@v3 versions. Check these notes: https://github.com/node-formidable/formidable/blob/master/VERSION_NOTES.md"

@GrosSacASac
Copy link
Contributor Author

So far we have dist-tags:

1.x: 1.2.4                  latest: 2.0.0
3.x: 3.1.1-canary.20211030  v3: 3.1.2-canary.20211030

@tunnckoCore
Copy link
Member

Should I run this command ?

if <2.0.0 works to deprecate all v1, yea.. but i'm not sure.

plus you should formidable@"^2.0.0-canary" to deprecate the canary usage

@tunnckoCore
Copy link
Member

So far we have dist-tags:

delete 3.x and v3

@tunnckoCore
Copy link
Member

Tried v2 tag but

By the way, did you tried v2.x or just v2 as dist-tag? It should work if don't have .x.. hmmm

@GrosSacASac
Copy link
Contributor Author

Deprecated all the 1.x and canary versions

@GrosSacASac
Copy link
Contributor Author

If I delete how are people going to install v3 ?

@GrosSacASac
Copy link
Contributor Author

I tried just v2

@GrosSacASac
Copy link
Contributor Author

GrosSacASac commented Oct 30, 2021

Ok so

npm i [email protected]
npm ERR! code ETARGET
npm ERR! notarget No matching version found for [email protected].

So 3.x is also invalid. and 2.x also.

I think it worked because the argument was passed from package.json (publishConfig)
So I rename to next-3 and latest-2 and latest-1 or ?

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

Hmm... their tag naming doesn't work well to us, hm.

v1

Move v1 to legacy dist-tag. Reserved for v1 specifically, formidable@legacy will always install just v1.

v2

Now on latest, AND v2-latest (should work cuz it's invalid version range).
Future not ready for release updates/bugfixes and things will be on v2-next, like the -canary until now.

v3

Move v3 to v3-latest (without date) and future not ready for release will be on v3-next, like the -canary until now.

We still can add the dates to the -next tags, like -next.20210312.

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

Renamed the branches to follow that. You should update your local copies with

for v1

git branch -m 1.x v1-legacy
git fetch origin
git branch -u origin/v1-legacy v2-legacy
git remote set-head origin -a

for v2

git branch -m 2.x v2-latest
git fetch origin
git branch -u origin/v2-latest v2-latest
git remote set-head origin -a

and for v3, copy the current master to v3-latest

Don't publish new versions, just point the dist-tags, i'll update the notes everywhere soon and publish patch versions.
I'll write and add RELEASE_POLICY or something to be more clear to all of us.

@tunnckoCore
Copy link
Member

tunnckoCore commented Oct 30, 2021

Okay, i got that.

latest: 2.0.1
legacy: 1.2.6
v1: 1.2.6
v2-next: 2.0.1
v2: 2.0.1
v3-next: 3.1.3
v3: 3.1.3

I'll fix the notes and bump the versions. In the *-next dist-tags we will publish prereleases.

@tunnckoCore
Copy link
Member

Switched all the tags and published all the versions. Seems like what you're saying is right, it works when it's on the publishConfig.tag so i switched them all to have such so we can stop thinking about --tag on npm publish. That probably should work with automation too. Well, i have some concerns cuz I built several tools that are around automation and they were using --tag. But anyway we won't have that much automation here, except Renovate which I should fix too, it seems.

@GrosSacASac
Copy link
Contributor Author

Nice, but we should remove v1 v2 and v3 tags from npm , because you think that installing @V3 will install from that tag, but because it is also a valid version range (as per npm) it will convert it to @>3 & <4 (And it will be even more confusing since it will look like it works initially)

@tunnckoCore
Copy link
Member

Ohhh yea, got that.. was just thinking about that.. ooooh fack.. 🤣

@tunnckoCore
Copy link
Member

Okay... as I thought before few hours.

  • for v1: legacy branch - legacy dist-tag
  • for v2: master branch - latest dist-tag
  • for v3: next branch - next dist-tag

When v3 should become latest on npm, we cut the master branch to v2 branch and merge next branch into master. And the next branch and dist-tag becomes for v4.

@tunnckoCore
Copy link
Member

Okay lets close this, continue here #769

@tunnckoCore tunnckoCore unpinned this issue Oct 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants