@raszi I would like to move tmp over to npmjs.com/tmp and github.com/tmp, if that is fine with you.
We both would then be owners of these organisations, so that either of us could make a new release and publish that to npmjs.com.
The main reason for this is that ATM I do not have any access to the repository as a maintainer and I am unable to publish new releases to npm in case of hotfixes that need to go out ASAP.
At the beginning, though, I want to publish one package @tmp/tmp-test-environment which can be used in conjunction with jest. (overcomes issues with jest and their use of child processes and also worker threads.)
The package would live under github.com/tmp/tmp-test-environment. for the time being, this can be using the existing tmp package. I already invited you as an owner of that github organisation, so please join the effort.
In order to keep the commit history of tmp we should make a clone and use that as a starter.
In the long run I would like to dissect tmp into multiple packages and also introduce some extra functionality, also getting rid of the listeners and make them separate packages that the user can then require as needed.
This will also include a rewrite using Typescript and will also introduce lerna for overall package and process management, with the core packages all located in a single mono repo.
For the time being, tmp and @tmp/* will coexist, until the new solution becomes stable.
In addition, I would like to start off with a 1.0.0-alpha release since the changes will be breaking and no backwards compatibility can be achieved. We would then migrate this to a 1.0.0-beta and 1.0.0-stable release as soon as possible.
Envisioned Changes
get rid of the FD support, tmp will no longer keep an open FD and the user will be responsible for opening the file as needed
~the sync api will be eliminated in favor of async/await and Promises, consolidating everything into a single and consistent interface~
existing callback based interfaces will be made async, where the user can either await the result or use the promise that is being returned
tmpName and tmpNameSync currently hand out names that a different process could always also generate, so we need to make sure that these names have been registered with the filesystem prior to that they are handed out to the user
when exposing the garbage collector as an interface, we must introduce some kind of locking mechanism, ATM the garbage collector will remove files that are still in use. it also has no knowledge on whether a given temporary directory is still in use and must not be garbage collected
@raszi I would like to move tmp over to npmjs.com/tmp and github.com/tmp, if that is fine with you.
We both would then be owners of these organisations, so that either of us could make a new release and publish that to npmjs.com.
The main reason for this is that ATM I do not have any access to the repository as a maintainer and I am unable to publish new releases to npm in case of hotfixes that need to go out ASAP.
At the beginning, though, I want to publish one package
@tmp/tmp-test-environmentwhich can be used in conjunction with jest. (overcomes issues with jest and their use of child processes and also worker threads.)The package would live under github.com/tmp/tmp-test-environment. for the time being, this can be using the existing tmp package. I already invited you as an owner of that github organisation, so please join the effort.
In order to keep the commit history of tmp we should make a clone and use that as a starter.
In the long run I would like to dissect tmp into multiple packages and also introduce some extra functionality, also getting rid of the listeners and make them separate packages that the user can then require as needed.
This will also include a rewrite using Typescript and will also introduce lerna for overall package and process management, with the core packages all located in a single mono repo.
For the time being,
tmpand@tmp/*will coexist, until the new solution becomes stable.In addition, I would like to start off with a 1.0.0-alpha release since the changes will be breaking and no backwards compatibility can be achieved. We would then migrate this to a 1.0.0-beta and 1.0.0-stable release as soon as possible.
Envisioned Changes