Open MaxGraey opened 4 years ago
Should we also consider publishing other things such as the loader with the same namespace?
loader already published under @assemblyscript
namespace.
Oh didn't know that. Cool!
The commit https://github.com/confio/cosmwasm/pull/118/commits/d0e1a2ca6b7eb0d3fb34aac23b225f36af25d664 contains an AssemblyScript setup with eslint + prettier + eslint-plugin-simple-import-sort. yarn lint
runs the checks and yarn lint --fix
fixes them, which also applies all the prettier rules. It works with the dbaeumer.vscode-eslint VSCode plugin and its auto-fixer. Feel free to borrow from that config.
I imagine such linter would be used to port existing TypeScript code to make it AssemblyScript compatible. Do others believe this to be something that the linter should do? What are some of the most important rules needed? I imagine the number one feature for the config would be to blacklist incompatible type signatures or perhaps even whitelist existing ones. This config could then be used together with any existing TypeScript eslint configurations that provide stylistic and other rules that are not specific to AssemblyScript code.
The commit CosmWasm/cosmwasm@d0e1a2c contains an AssemblyScript setup with eslint + prettier + eslint-plugin-simple-import-sort.
yarn lint
runs the checks andyarn lint --fix
fixes them, which also applies all the prettier rules. It works with the dbaeumer.vscode-eslint VSCode plugin and its auto-fixer. Feel free to borrow from that config.
How do you handle usage of annotations? They seems to be causing eslint parser errors
I cannot run Prettier on AssemblyScript .ts
files with annotations (decorators), similar to what @mpetrunic mentioned. Prettier will quit re-formatting a .ts
file with
[error] src/assembly/wasm.ts: SyntaxError: Leading decorators must be attached to a class declaration
I have tried
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore: decorator
// prettier-ignore
but none of these directives help.
I have resorted to commenting out all of my @inline
annotations before running Prettier, and then un-commenting them afterwards. Is anyone else having this problem?
@ebrensi Yes! Which is why I've been using eslint see sample config here.
With TS to AS linter you could things like deno -run_as_wasm code.ts
@HerrCai0907 made this. It fixes the problem of prettier :)
On recent bi-weekly meeting we talked about lint system. Currently we have very basic rules for ts-lint but first of all it only for internal usage and development process, secondary it pretty basic and don't cover all special cases and finally it based on ts-lint which not so powerful as eslint which already supported by typescript. So basic plan:
1) Migrate to eslint; 2) Add more custom rules via plugins (need further discussion); 3) Add default preset; 4) Publish it to npm as
@assemblyscript/linter
?