Correct package.json name to rdfjs org #4

blake-regalia · 2020-11-10T04:52:43Z

No description provided.

tpluscode · 2020-11-10T06:37:46Z

What is the benefit of this change? Keeping the name rdf-js will not require any changes in code.

If we do this, however, everyone will have to update all of their imports.

blake-regalia · 2020-11-10T07:03:35Z

Nothing has to break, we can publish over rdf-js to proxy this package. Bringing the package under the rdfjs org aligns it with this repo and signals that it is endorsed and maintained by the RDFJS team.

matthieubosquet · 2020-12-17T14:53:48Z

That sounds awesome, I do agree it would bring clarity and consistency!

I still find it hard to find my way through the RDF JS ecosystem and its many libraries. Having an authoritative namespace under which a few packages are maintained and considered canonical implementations is a big plus to not be discouraged. As a developer, I find it much more intuitive and less confusing to install @rdfjs/types which I know is endorsed by the Community Group.

Also, rdf-js was last published two years ago anyway and this is a major release so for someone updating their types, the simple action of installing a new package seems like a fairly small overhead. Which brings me to think it's a sensible time to do it.

tpluscode · 2020-12-17T20:47:28Z

So we then agree to publish both rdf-js and @rdfjs/types?

matthieubosquet · 2020-12-17T20:53:21Z

Alternatively, rdf-js could be deprecated and point to the newer @rdfjs/types for people wishing to update to the major version 2.x of the types. I think that solution would defuse potential confusion and allow people to organically discover that the types have a new major release and slowly migrate to the canonical URL rather than having rdf-js linger around forever.

The other question that seemed more important is how to proxy @types/rdf-js to the canonical/authoritative @rdfjs/types. It seems unclear what the best way forward in that matter is. But I don't think it should hold off publishing @types/rdf-js.

tpluscode · 2020-12-17T21:00:24Z

Alternatively, rdf-js could be deprecated

I'm still not convinced. Keeping rdf-js does not break anyone's code. Even if it's only s/rdf-js/@rdfjs\/types/ I think it's unnecessarily disruptive. All everyone would otherwise change is the package.json entry

The other question that seemed more important is how to proxy

You mean what happens when we finally start publishing our own package? I have not experienced it first hand as typings author but Definitely Typed has a policy for removing packages. They recommend removing the @types/ package as soon as we publish our own. At which point I think an empty package is published with deprecation warning on npm install.

matthieubosquet · 2020-12-17T22:13:16Z

The current situation is already disruptive since there are two concurrent packages rdf-js and @types/rdf-js and in fact, on the homepage of the rdf-js package it clearly states: "Do not install this package directly". See: https://www.npmjs.com/package/rdf-js

As a result and for the past 2 years, I think most people (including me and most of the recent repositories I've encountered) have been relying on @types/rdf-js, not on rdf-js. If removing the @types/rdf-js package is ok in your opinion, I don't see how deprecating rdf-js is a problem in comparison.

First, deprecating rdf-js will not force anyone to update their dependency, once again to a new major so not an automatic update anyway, it will instead show a deprecation message when they install it incentivising them to install the authoritative/canonical package. See: https://docs.npmjs.com/using-deprecated-packages.

Second, there is nothing in the rdf-js package name that hints towards the fact that it is a types library rather than an implementation of the RDF/JS specification. It confused everyone I've talked to.

Third, The brand name RDF/JS is a great asset, it would be a shame not to use it. Including it in the package name makes the endorsement/source clear and it's very helpful/reassuring, even more so to new developers of which we can only hope there will be more in the future.

Thanks for the link to the policy for removing packages on DefinitelyTyped, it makes things clearer. Great to see that this process properly deprecates @types packages and links them to the relevant repo. See: https://www.npmjs.com/package/@types/3d-bin-packing

tpluscode · 2020-12-18T08:38:18Z

Curious that I have never experience the confusion you refer to. Let me give you a complete example.

I think most people have been relying on @types/rdf-js, not on rdf-js.

You only consider package.json? Any project using the types will install @types/rdf-js, which pretends to be type declarations for rdf-js. (The fact that this package actually exists is right now irrelevant).

Thus, in code you will find imports like:

import { NamedNode } from 'rdf-js'

By reviving rdf-js for the types no code will have to change. The next patch release of @types/rdf-js will simply install rdf-js as its dependency and thus all other @types packages which depend on RDF/JS spec (for example type for parsers/serializers) will continue to seamlessly work because all of their imports will still be valid.

If removing the @types/rdf-js package is ok in your opinion, I don't see how deprecating rdf-js is a problem in comparison.

Again, the current package will not be removed. It will simply proxy to a new "real" package to ease adoption. How it "is a problem in comparison"? Read below

Now, changing the name to @rdfjs/types will completely break everyone. I expect that the necessary updates will create a snowball effect and it will likely continue until everyone migrates to the new package.

The problem is similar to what can happen if you somehow end up with multiple versions of @types/rdf-js. Duplicate declarations of type can be falsely identified as incompatible in weird places in your modules, preventing successful build.

So while I agree that if we were starting from a clean slate, I too would opt for a more natural, less confusing package name, at this point we do not have that luxury. We're looking at an existing ecosystem which we cannot afford to break and that should trump the arguments about people being confused.

tpluscode · 2020-12-18T08:42:45Z

Nothing has to break, we can publish over rdf-js to proxy this package.

@blake-regalia, so you propose to publish rdf-js with a single index.d.ts module?

export * from '@rdfjs/types`

rubensworks · 2021-01-04T07:10:19Z

Apologies for the late reply, but I agree with @tpluscode's stance on this.

Using this other package name will be break all existing packages, requiring them to change all imports.
Whereas just migrating to rdf-js would allow people to keep all of their existing code unchanged (and be compatible with other packages that have not yet been updated to the new typings).

So I'm against merging this PR.

blake-regalia · 2021-03-15T07:01:16Z

Coming back to this thread, I suggest we deprecate the other packages and point to o@rdfjs/types as the single source of truth for RDFJS typings. Package deprecation is not a big deal guys. Let's clean this up once and for all.

tpluscode · 2021-03-15T11:57:57Z

@blake-regalia you agree with my #4 (comment) ?

As long as we won't have everyone change their imports right away I can agree with what happen's here

blake-regalia · 2021-03-15T16:24:53Z

I initially proposed making rdf-js a proxy lib, but then we would have to maintain two packages in order to keep semvers up to date. I believe the more appropriate course of action here is to simply deprecate the other package and point users to the scoped package @rdfjs/types. Keep in mind, nobody's code will break. When they are ready to migrate then they can do so.

More technically: I would propose publishing a new minor semver version of rdf-js and then immediately deprecate only that version. This would ensure that when a user installs a module that depends on rdf-js they are not met with a deprecation message. When developers are ready to upgrade however, then they can perform migration.

tpluscode · 2021-03-15T19:48:45Z

Word of caution

The proxy package could just have a single version and a dependency on "@rdf-js/types": "*". Actually trying to use sem ver is asking for trouble. Conflicting versions of multiple types versions easy lead to weird npm/yarn resolutions and broken build. We had a long discussion about @rdfjs/data-model which had a dependency on a specific version of the types. It was a constant issue until it became a "star" dependency. (rdfjs-base/data-model#24 (comment))

blake-regalia · 2021-05-06T05:56:11Z

Started an open discussion in DefinitelyTyped gitter channel to clarify the removal/deprecation process here: https://gitter.im/DefinitelyTyped/DefinitelyTyped?at=609382c70845c416dcc8497b

blake-regalia · 2021-05-06T06:18:20Z

After a productive discussion with @tpluscode - I agree with the proxy package which has a wildcard dependency on the @rdfjs/types package.

I will be merging this PR now that we have resolved how to proceed with the DefinitelyTyped package.

tpluscode · 2021-05-06T06:29:37Z

I believe we need a new repo for rdf-js and publishing setup? @rubensworks, you previously published that on NPM...

rubensworks · 2021-05-06T06:33:58Z

I believe we need a new repo for rdf-js and publishing setup?

Isn't that the purpose of this repo here? Also #3.

@rubensworks, you previously published that on NPM...

That's just a stub package, we can easily publish over that when we get to that point :-)

tpluscode · 2021-05-06T06:37:02Z

Isn't that the purpose of this repo here?

In which case I come back to proposing a monorepo, albeit with one of the two packages really not changing much, and changesets to make publishing easy for maintainers

when we get to that point :-)

we are very close to that point

rubensworks · 2021-05-06T06:42:46Z

one of the two packages

What packages do you have in mind?
I see only one package (the one coming from @types/rdf-js).

tpluscode · 2021-05-06T06:44:18Z

@rdfjs/types -> the real one we have here right now
rdf-js -> a proxy package

rubensworks · 2021-05-06T06:49:25Z

Ah ok, so actually there will be 2 proxy packages: @types/rdf-js will be a proxy to rdf-js, and rdf-js will immediately also be a proxy to @rdfjs/types.
Thanks for the clarification!

Since rdf-js should not need further changes after its initial release, it might be better to just have a separate repo for this, which we can then ignore.

tpluscode · 2021-05-06T06:50:42Z

Since rdf-js should not need further changes after its initial release, it might be better to just have a separate repo for this, which we can then ignore.

Yes, also an option :)

blake-regalia · 2021-05-15T18:17:11Z

Sounds good to me

The package has been moved off DefinitelyTyped by upstream: DefinitelyTyped/DefinitelyTyped#51756 and rdfjs/types#4.

Correct package.json name to rdfjs org

f97793d

RubenVerborgh approved these changes Dec 17, 2020

View reviewed changes

tpluscode mentioned this pull request Mar 15, 2021

remove rdf-js DefinitelyTyped/DefinitelyTyped#51756

Merged

9 tasks

tpluscode mentioned this pull request May 5, 2021

Swap this for Dataset<OutQuad, InQuad> in return of intersection #8

Merged

blake-regalia merged commit 0ebac16 into master May 6, 2021

blake-regalia deleted the fix/package-name branch May 6, 2021 06:26

Vinnl added a commit to inrupt/solid-client-js that referenced this pull request Jun 4, 2021

Migrate to @rdfjs/types from @types/rdf-js

b872c19

The package has been moved off DefinitelyTyped by upstream: DefinitelyTyped/DefinitelyTyped#51756 and rdfjs/types#4.

Vinnl mentioned this pull request Jun 4, 2021

Migrate to @rdfjs/types from @types/rdf-js inrupt/solid-client-js#1071

Merged

Vinnl added a commit to inrupt/solid-client-js that referenced this pull request Jun 4, 2021

Migrate to @rdfjs/types from @types/rdf-js

459bf2e

The package has been moved off DefinitelyTyped by upstream: DefinitelyTyped/DefinitelyTyped#51756 and rdfjs/types#4.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Correct package.json name to rdfjs org #4

Correct package.json name to rdfjs org #4

blake-regalia commented Nov 10, 2020

tpluscode commented Nov 10, 2020

blake-regalia commented Nov 10, 2020

matthieubosquet commented Dec 17, 2020 •

edited

Loading

tpluscode commented Dec 17, 2020

matthieubosquet commented Dec 17, 2020 •

edited

Loading

tpluscode commented Dec 17, 2020 •

edited

Loading

matthieubosquet commented Dec 17, 2020 •

edited

Loading

tpluscode commented Dec 18, 2020 •

edited

Loading

tpluscode commented Dec 18, 2020

rubensworks commented Jan 4, 2021

blake-regalia commented Mar 15, 2021

tpluscode commented Mar 15, 2021

blake-regalia commented Mar 15, 2021

tpluscode commented Mar 15, 2021 •

edited

Loading

blake-regalia commented May 6, 2021

blake-regalia commented May 6, 2021

tpluscode commented May 6, 2021

rubensworks commented May 6, 2021

tpluscode commented May 6, 2021

rubensworks commented May 6, 2021

tpluscode commented May 6, 2021

rubensworks commented May 6, 2021

tpluscode commented May 6, 2021

blake-regalia commented May 15, 2021

Correct package.json name to rdfjs org #4

Correct package.json name to rdfjs org #4

Conversation

blake-regalia commented Nov 10, 2020

tpluscode commented Nov 10, 2020

blake-regalia commented Nov 10, 2020

matthieubosquet commented Dec 17, 2020 • edited Loading

tpluscode commented Dec 17, 2020

matthieubosquet commented Dec 17, 2020 • edited Loading

tpluscode commented Dec 17, 2020 • edited Loading

matthieubosquet commented Dec 17, 2020 • edited Loading

tpluscode commented Dec 18, 2020 • edited Loading

tpluscode commented Dec 18, 2020

rubensworks commented Jan 4, 2021

blake-regalia commented Mar 15, 2021

tpluscode commented Mar 15, 2021

blake-regalia commented Mar 15, 2021

tpluscode commented Mar 15, 2021 • edited Loading

blake-regalia commented May 6, 2021

blake-regalia commented May 6, 2021

tpluscode commented May 6, 2021

rubensworks commented May 6, 2021

tpluscode commented May 6, 2021

rubensworks commented May 6, 2021

tpluscode commented May 6, 2021

rubensworks commented May 6, 2021

tpluscode commented May 6, 2021

blake-regalia commented May 15, 2021

matthieubosquet commented Dec 17, 2020 •

edited

Loading

matthieubosquet commented Dec 17, 2020 •

edited

Loading

tpluscode commented Dec 17, 2020 •

edited

Loading

matthieubosquet commented Dec 17, 2020 •

edited

Loading

tpluscode commented Dec 18, 2020 •

edited

Loading

tpluscode commented Mar 15, 2021 •

edited

Loading