feedback doesn't disappear after some time when saving a project

[ntraut]

i think it would be better that the feedback stays only a limited time, in that way if we save again the project and it worked again we don't have the impression that nothing happened.

[dhovart]

Ah, yes, thanks for raising this issue.

I think that UX-wise it's a bad practice to have the feedback disappear, because it may be an accessibility issue. When I was trained on accessibility in my previous job I remember that the speaker would tell us that generally we should avoid having things disappear after a short period of time as people with cognitive limitations or low vision may need more time to read the content. I don't know how much you care about accessibility, but I think there are many improvements that could be made in this regard.

I think maybe a subtle flash of the content as a visual feedback is enough to tell that something has happened. Maybe adding an aria-live region too.

And also this has nothing to do but I think at some point I should transfer the repository over to you, so that it stays with the other neuroweblab projects. And give you access to the NPM admin!

[ntraut]

yes, that's definitely a problem that we should see with @r03ert0 and @katjaq, i don't remember how it was before but maybe the feedback should be more visible like more colorful for example.

i don't know how you accorded but of course it would be more logical if this repo was owned by the neuroanatomy group, i also hope we could get an npm account to transfer the ownership of the npm package, which is easier to manage as a dependency than a simple github repo.

[dhovart]

ok! I will add you as maintainers but you need to create an account on npm first. For the repository transfer it's possible but I need to have respository creation permission in neuroanatomy (or maybe I can transfer to it to you first, and then you transfer it to neuroanatomy)

[katjaq]

Thanks for all the discussion & planning above. I invited you to neuroanatomy @dhovart . Once accepted, I will check to set your rights accordingly if not already good :) Thank you both! 🚀

[dhovart]

@katjaq thank you for adding me to the organisation but I still don't have rights to create a public repository. The transfer is denied

[ntraut]

@katjaq thank you for adding me to the organisation but I still don't have rights to create a public repository. The transfer is denied

@katjaq from what i found the way do to is to allow all members to create repos, i'm not sure there is a way to allow specific members to create repos

https://docs.github.com/en/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization

@r03ert0 thinking of it i don't think that's a good idea to use github dependency instead of npm dependency. we already saw that we can't properly link to a specific version with github dependencies, and nwl evolves fastly so only a specific version can work with brainbox or microdraw. if we are not able to link to a specific version, when trying to revert brainbox or microdraw to a specific commit we might have trouble to find the right nwl version to install...

[r03ert0]

@ntraut: with github you can link to a specific release. You can give your releases any name, but we have often tried to use semantic versioning. In that case, is there still a difference with an npm package? I'd rather not have to maintain an NPM account if that's not necessary. I think you were linking to a specific commit, that I agree doesn't seem to be fantastic...

[ntraut]

i think that we have the same problem with git tags as with git commit hashes: npm doesn't really pay attention to them when doing npm install (as least when it's already installed), so to really update we have to do npm install neuroweblab after, but doing so we lose the track of the version, so we are in the uncertainty if the version specified in package.json (or package-lock.json in case of no version specified in package.json) is working.

[r03ert0]

could you verify? It is possible to install a specific tag of a github repo using npm install use_name/node_project@version (more info). The question is whether that makes it into package.json...

[ntraut]

could you verify? It is possible to install a specific tag of a github repo using npm install use_name/node_project@version (more info). The question is whether that makes it into package.json...

that's weird, that's a top google ranked blog post but they got wrong, npm doesn't support the installation of github packages using @version . i tried npm install shelljs/shelljs@v0.7.6 and directly got an error. with npm install shelljs/shelljs#v0.7.6 it installs the package at the desired version, but after i modify the version in package.json to "github:shelljs/shelljs#v0.8.0" and run npm install, npm doesn't update the package, exactly the same issue as when using commit hashes.

(i'm using npm 8.1.2 which not the newest but not too old, still newer than the blog post you are referring)

[r03ert0]

it's weird indeed. I did as you, and even package-lock.json gets updated to v0.8.0, however, nothing seems to be downloaded 🤔

[r03ert0]

running npm update does update from 0.7.6 to 0.8.0, though.

[ntraut]

that's true, so should we do npm update instead of npm install when wanting to update the packages after git pull? npm update seems longer to execute, 1m vs 15s in my computer, also we will have a package-lock.json which will be always different from the repo one. not sure what to do in this condition, maybe stop indexing it?

[dhovart]

I don't think you can avoid hosting it on a package management server in this case.

The library needs to be built and pushed somewhere, as it's packaged as an ES and UMD module. What's loaded in node_modules when you install the library is the content of the dist folder (which is not part of this repository source) as you can see in package.json.

Having a npm account is not such a hassle. Once everything is set up you forget ever having one and just need to run npm publish from the command line whenever you want to release a new version.