google / dart_cli_pkg Goto Github PK

when having a package.json file with exports like

"exports": {
  "types": "./path/to/types"
}

This currently becomes

"exports": {
  "default": "./${pkg}.default.dart.js"
}

Ideally this should become

"exports": {
  "types": "./path/to/types"
  "default": "./${pkg}.default.dart.js"
}

Note that "exports" can also be string|string[], so the feature request is to keep the behavior of overwriting the field if it was either string|string[]|undefined|null however when the field had value {} (or Map in dart) then use the spread operator and only overwrite "node", "browser", and "default" when specified.

See sass/dart-sass#1714

This is pretty easy since it doesn't require any building, but it's still something we should support.

I am assuming this is specific to Homebrew...

When Dart is installed with Homebrew, and running the pkg-npm-dev grinder task, I get the following crash:

pkg-npm-dev
  writing build/npm/package.json
  copying build/abc.dart.js to build/npm

FileSystemException: Cannot open file, path = '/usr/local/Cellar/dart/2.7.1/libexec/LICENSE' (OS Error: No such file or directory, errno = 2)
#0      _File.throwIfError (dart:io/file_impl.dart:645:7)
#1      _File.openSync (dart:io/file_impl.dart:489:5)
#2      _File.readAsBytesSync (dart:io/file_impl.dart:549:18)
#3      _File.readAsStringSync (dart:io/file_impl.dart:594:18)
#4      license.<anon> (package:cli_pkg/src/utils.dart:94:52)
#5      new Future.sync (dart:async/future.dart:224:31)
#6      AsyncMemoizer.runOnce (package:async/src/async_memoizer.dart:43:45)
#7      license (package:cli_pkg/src/utils.dart:82:44)
#8      _buildPackage (package:cli_pkg/src/npm.dart:380:50)
#9      addNpmTasks.<anon> (package:cli_pkg/src/npm.dart:194:27)

Here are the various files in that Homebrew installation:

~/code/abc/server:$ ls -FlAh /usr/local/Cellar/dart/2.7.1/libexec/
total 24
drwx------  15 sam  admin   510B Jan 23 05:07 bin/
-rw-r--r--   1 sam  admin   189B Jan 23 04:08 dartdoc_options.yaml
drwxr-xr-x   5 sam  admin   170B Jan 23 04:08 include/
drwxr-xr-x  29 sam  admin   986B Jan 23 04:11 lib/
-rw-r--r--   1 sam  admin    41B Jan 23 04:08 revision
-rw-r--r--   1 sam  admin     6B Jan 23 04:08 version

~/code/abc/server:$ ls -FlAh /usr/local/Cellar/dart/2.7.1/
total 24
drwxr-xr-x   3 sam  admin   102B Feb 20 21:15 .brew/
-rw-r--r--   1 sam  admin   584B Feb 20 21:15 INSTALL_RECEIPT.json
-rw-r--r--   1 sam  admin   1.5K Jan 23 04:05 LICENSE
-rw-r--r--   1 sam  admin   936B Jan 23 04:05 README
drwxr-xr-x  11 sam  admin   374B Feb 20 21:14 bin/
drwxr-xr-x   8 sam  admin   272B Feb 20 21:14 libexec/

This should support building the CLI app via dart2js and injecting a prelude so that it can be run directly via node.js.

Copied from sass/dart-sass#1678:

Could you please provide checksums of the assets we download from the release page? An integrity check is a good practice after downloading over the net.

For example, Docker Compose is doing this: https://github.com/docker/compose/releases

If the user wants to distribute a browser-compatible library, the CommonJS require()s we generate aren't ideal. They can work with the aid of a bundler, but they can't be loaded directly by the browser. If the user has chosen to generate a browser-compatible library, we should generate a <pkg>.browser.js that uses ESM for all its loads. This also means that we should inject all loads in this case rather than including any directly in the .dart.js preamble.

Specifically:

• We should add a pkg.jsSupportsBrowser option that indicates whether the jsModuleMainLibrary can be loaded on a browser. It should default to true iff pkg.jsModuleMainLibrary is set and pkg.jsRequires contains a require whose target is JsRequireTarget.browser or JsRequireTarget.all. JS generation should throw an error if pkg.jsSupportsBrowser is set to true and pkg.jsModuleMainLibrary is unset.

• If pkg.jsSupportsBrowser is true and any dependencies are detected (either through pkg.jsRequires or extracted from the compiled code), all dependencies should be injected and a <pkg>.browser.js file should be generated which loads the dependencies and <pkg>.dart.js using ESM imports.

dart2native supports generating fully standalone executables, and we should ideally support this as well for standalone compilation. There are some complications, though: on OS X and Windows, standalone executables need to be signed or they'll produce scary and annoying warnings when they're run. This requires that users purchase a trusted certificate for each OS and run a command to sign the generated executables with those certificates. See details for OS X and Windows.

I think the best way to handle this would be to have pkg.standaloneWindowsCert and pkg.standaloneMacOSCert fields and, if those fields are set, generate full standalone executables and sign them. I don't think it's especially useful to generate unsigned executables; they won't be much faster than native snapshots, and the generated warnings will be very frustrating.

Note that for Linux, this is much easier, since code signing isn't required. Given that all three supported operating systems are substantially different here, I'm going to split this up into three tasks:

• Linux
• Windows
• Mac OS

We should run Travis CI tests on Windows, Linux, and Mac OS.

Packages like sass (built from the dart-sass repo) do expose Future's in their NPM output for exported functions. This is not desirable in NodeJS and ideally native Promise constructs would be returned.

Initially conversion for this has been proposed to the dart-sass repo, but it looks like this could be automatically captured in the
NPM task that creates the JS interop main wrapper.

Related: sass/dart-sass#932

All deployments require credentials, and making those credentials available to the deploy steps can be error-prone and annoying. We should provide a way to do this configuration on the user's behalf.

One possibility would be to provide our own pub run-based CLI which would authenticate with the various services and write the result to the user's .travis.yml.

This should support building a Chocolatey package and uploading it to the Chocolatey repository.

I'm trying to compile a dart script under windows:

dart2native -v log.dart
Generating AOT kernel dill.
Generating AOT snapshot.

Unexpected object (Class with illegal cid, full-aot): 0x1f79ed954b1 Library:'dart:collection' Class: _CompactLinkedHashSet@3220832

Failed to generate native files:
Generating AOT snapshot failed!

The following script is sufficient to generate the error:

Create the script:

log.dart

import 'package:logger/logger.dart';

void main() {
 Log.e();
}

class Log extends Logger {
  Log();

  factory Log.e() {
    var self = Log();
    self.e('a');
    return self;
  }
}

Then run:

dart2native log.dart

OS : windows
OS Version : "Windows 10 Enterprise Evaluation" 10.0 (Build 18363)
Path separator : \

dart version : 2.7.1

dart exe path : c:\program files\dart\dart-sdk\bin\dart.exe
dart path : c:\program files\dart\dart-sdk\bin\dart.exe : c:\program files\dart\dart-sdk\bin\dart.exe
dart2Native path : c:\program files\dart\dart-sdk\bin\dart2native.bat : c:\program files\dart\dart-sdk\bin\dart2native.bat

pub get path : c:\program files\dart\dart-sdk\bin\pub.bat : c:\program files\dart\dart-sdk\bin\pub.bat
Pub cache : c:\users\user\appdata\roaming\pub\cache
Package Config : c:\users\user\file:\c:\users\user\dshell.packages

Users of this package will probably want to run tests on their executables under both the Dart VM and Node.js. We should provide a testing library with utilities to make this easier, a

• A way of ensuring that the generated JS is up-to-date.
• A way of ensuring that the generated VM snapshot is up-to-date, but only if it exists.
• Utilities for starting TestProcesses for JS or the VM.
• Maybe a way of making it easy to define tests that run on both the VM and JS?

unused dart:async as Future and Streams are already implemented in dart:core as per Dart 2.1.

if you call dart2native with a symlink to the dart file dart2native fails with the error:

dart2native xxx.dart
xxx.dart is not a file. See '--help' for more information.

Under linux dart2native works fine with a symlink.

I'm the developer of dshell:
https://pub.dev/packages/dshell

One of the objectives of dshell is to allow users to create 'single file' dart scripts that are still able to use a set of dependencies whilst not having a pubspec.yaml.

Dshell does this by providing its own compile option:
dshell compile xxx.dart

During compilation dshell creates a 'virtual project directory' ( VPD) and generates a pubspec.yaml with a set of globally defined package dependencies.

The VPD includes a symlink to the dart script (xxx.dart) and possibly to a lib directory (if one exists).

It then runs dart2native against the symlink script using the above VPD as the working directory.

The result is that the .packages and pubspec.lock files are all created in the VPD leaving the user with a clean single file script.

Dshell also allows the user to specify additional dependencies in the script by way of annotations (@pubspec). This again is about supporting the concept of a single file script.

A key goal of dshell is to replace bash as the go to tool for cli scripting hence the aim of allowing users to create a single file script akin to a bash script.

The same symlink is also used to run the script.
Using a shebang a user is able to run a dshell script:

./head.dart

This process again uses the VPD and its associated pubspec.yaml.

The work around for dshell is to copy the script (xxx.dart) to the virtual project directory each time the user goes to run the script. The downside is the additional startup time the copy creates and the slightly uncomfortable fact that the user now has two copies of the script on their system.

So it would be nice if dart2native supported symlinks on windows as it does on linux.

The complete command I run to compile a script called head.dart is:

head.project is the name of the VPD.

dart2native.bat C:\Users\User\AppData\Roaming\.dshell\cache\head.project\head.dart 
--packages=C:\Users\User\AppData\Roaming\.dshell\cache\head.project\.packages --output=c:\users\user\dshell\head"

This is based on a moderation "suggestion" made by the Chocolatey team.

"It would be good if you could rename the LICENSE file when it gets packaged to be named LICENSE.txt - that way it can be easily previewed from the chocolatey website."

In updating the migrator to use this, I ran into an issue with the testing library.

The functions in the testing library say to pass the basename of the entrypoint script as the executable argument, which works for the snapshot built with pkg-compile-snapshot-dev, which is stored at build/$basename.dart.snapshot.

However, pkg-npm-dev the other JS build tasks use the name of the executable in pkg.executables, so that binary is stored at build/npm/$exectuable.js

For the migrator, the executable name is sass-migrator while the basename of the entrypoint is sass_migrator, so I can either pass sass_migrator to pkg.start et al to make it work with the Dart snapshot or sass-migrator to make it work with Node, but not both.

see https://github.com/sass/dart-sass/releases/tag/1.28.0 for an example:

This should support deploying to a Homebrew repository.

This will probably require that the user configure the Git URL to and path within the repository in question so that the deploy process can overwrite the brew script.

This should support deploying the CLI app, built as JS, to npm.

Blocked on #4

When running the command, everything works well, but the Changelog.md section for the version is displayed without the line breaks.

Please view the following link:
https://github.com/leoafarias/fvm/releases/tag/2.0.0

When digging into the code, it seems that this was done by design. (or maybe I am missing something)
https://github.com/google/dart_cli_pkg/blob/master/lib/src/github.dart#L190

Before making any changes to this, I wanted to make sure this change can be done so it's formatted correctly.

Hi,

I'm getting an error that I didn't get before in GitHub Actions:

pkg-compile-native
  failed: Your SDK doesn't have dart2aot or dart2native. This probably means that you're using a 32-bit SDK, which doesn't support native compilation.

GrinderException: Your SDK doesn't have dart2aot or dart2native. This probably means that you're using a 32-bit SDK, which doesn't support native compilation.
#0      GrinderContext.fail (package:grinder/src/grinder_context.dart:42:5)
#1      fail (package:grinder/src/grinder_context.dart:59:39)
#2      _compileNative (package:cli_pkg/src/standalone.dart:81:5)
#3      _rootRun (dart:async/zone.dart:14[26](https://github.com/filiph/linkcheck/runs/6373828609?check_suite_focus=true#step:8:26):13)
...
Error: Process completed with exit code 1.

Whole run here.

Is this because dart2aot and dart2native do not exist anymore? Or has something changed with the default Dart binaries that prevents cli_pkg to do its work inside GitHub Actions?

Here is the setup, which I'm told is very standard:

• GitHub actions workflow: https://github.com/filiph/linkcheck/blob/master/.github/workflows/release.yml
• grind.dart: https://github.com/filiph/linkcheck/blob/master/tool/grind.dart

This should be able to create GitHub releases and upload package tarballs to those releases. It should also be able to auto-generate release notes from the existing changelog.

I tried enabling the "can be invoked" test in standalone_test.dart on Windows when the dart2native executable exists (because dart-lang/sdk#37897 is no longer a factor), but the relative symlink executable assertion failed with:

ProcessException: The filename, directory name, or volume label syntax is incorrect.
  
Command: C:\Users\travis\AppData\Local\Temp\dart_test_2cca631b-f072-11e9-8356-00155d619c92\foo-relative

I can't figure out what's going wrong a priori, so it will probably require debugging on a real Windows device.

The fix in #122 still fails on Node v14, where logical OR assignment is not supported.

See e.g. https://github.com/sass/dart-sass/actions/runs/4558130003/jobs/8040642513

Apparent the dart-sass project uses this project to create the executables. When I created a relative symbolic link to the dart-sass shell script it failed to execute on linux because readlink does not return the full path. In this case readlink -f is needed, however I see that it is not used because of an issue on OS X.

Please see sass/dart-sass#978 for more details.

Hi there,

Are you considering "Compiling and Uploading to WinGet". Firstly, I actually don't know anything about this process(I am a total noob when it comes to creating/deploying package), I am here because of leoafarias/fvm#458.

I understand why chocolatey was used for windows(and I don't want that to change) but I was just wondering if winget was being considered since it comes by default in all new windows installations and I(any maybe others like me) don't want to install one more stuff if possible.

As requested in sass/dart-sass#1164 it would be nice for Dart-SASS and other users (such as FVM of this package to have support for producing Debian packages.

If no one wants to tackle this first, I'll have a go at adding support for this when I get a chance.