- Support headers in fetch()
- Adds many async fs functions:
deno.rename() deno.remove(), deno.removeAll(), deno.removeSync(),
deno.removeAllSync(), deno.mkdir(), deno.stat(), deno.lstat()
deno.readFile() and deno.writeFile().
- Add mode in FileInfo
- Access error codes via error.kind
- Check --allow-net permissions when using fetch()
- Add deno --deps for listing deps of a script.
Originally we planned to have a JS class for each error code. But it
seems better to just have a single DenoError class with a "kind"
property. One nice thing about using an enum instead of classes for
errors is that switch() can be used during error handling instead of a
bunch of instanceof branches.
Refactors handlers.rs
The idea is that all Deno "ops" (aka bindings) should map onto
a Rust Future. By setting the "sync" flag in the Base message
users can determine if the future is executed immediately or put
on the event loop.
In the case of async futures, a promise is automatically created.
Errors are automatically forwarded and raised.
TODO:
- The file system ops in src/handler.rs are not using the thread pool
yet. This will be done in the future using tokio_threadpool::blocking.
That is, if you try to call them asynchronously, you will get a promise
and it will act asynchronous, but currently it will be blocking.
- Handlers in src/handler.rs returned boxed futures. This was to make
it easy while developing. We should try to remove this allocation.
* Add forgotten --eol argument to 'git ls-files'. Without it, in certain
edge cases, files might have their mtime restored when it shouldn't.
* Don't parse ls-files output into fields; it's unnecessary.
* Disable the pip cache dir, and stop saving it to the appveyor cache.
* Leverage the 'git -C «dir»' flag to make a script shorter.
* Fix some factually and/or grammatically incorrect comments.
- Adding a ModuleId type alias to specify original url or local file of
dependency
- Modifying ModuleMetaData class to contain ModuleId
- Adding a --deps flag
https://github.com/denoland/deno_install
1. This allows the installer to use a more aggressive CI build matrix
with different version of python.
2. Running the installer during tools/test.py artificially inflates our
download stats.
3. Running the installer during tools/test.py makes the test script
dependent on having an internet connection.
4. Running the installer during tools/test.py introduces a race
condition during release - where it tries and fails to download the
latest release in build process that should be uploading that release.
