Coming soon - improved JavaScript and TypeScript Intellisense

As a self-proclaimed lazy developer, there’s nothing more important to me than having my tools “just work”. I’ve been frustrated by the fact that we are able to generate typescript declarations from a candid file, but that there has been no common pattern for getting nicely inferred types from our auto-generated actors. That is changing soon.

Changes to dfx

The file structure inside of .dfx/local/canisters/{canister_name} will change a bit. {canister_name}.js is renamed to index.js, and {canister_name}.d.ts is now {canister_name}.did.d.ts.


The new index.js will be significantly different, as well. Now, instead of exporting the canisterId and the idlFactory from the .did.js file, we have a createActor function that initializes the actor with sensible defaults. It now relies on process.env as a pattern to recognize the canister id, and returns an actor that has been automatically linked with the _SERVICE types from the typescript declarations.

Changes to DFX New

To support the new process.env patterns, there are also changes to the default project. Webpack.config.js is now slightly simplifed, and assumes you will be generating a single webpack config. It comes along with npm start, giving you hot reloading with asset management and a proxy to localhost:8000 by default.

Package.json will also be modified with a new “copy:types” command. As a postbuild step, npm will copy the autogenerated types out of .dfx/local and into your src directory, allowing you to commit the files.

Moving the files is necessary for correctly inferring types from the auto-generated code, and the alias pattern we had been using in webpack created difficulties when working with TypeScript or using bundlers other than Webpack.

Request for comment

How do you feel about these changes? There will be incremental improvement from this point forward, but this may be a breaking change for some of your frontends. I hope that the benefits pay off though!


Awesome, I remember @claudio referring to that features (typings) a few months ago.

1 Like

Everything here sounds good!

1 Like

This is very helpful for beginners. Right now we have a factory file that creates Actor instances, but this change would make that almost entirely obsolete.

@Hazel created a shell script to generate candid types and TypeScript types, which works, but I can imagine that people that just got started will have a hard time figuring that out so that’s also more than welcome.

I don’t suspect this will require big changes to our codebase to tie things together again.

Great work Kyle!

1 Like

Down the road I’ll replace the “copy” step with a “generate types” step that will be configurable in dfx.json. The starter code is only a starting point though, and there will need to be additional configuration if you start to talk to more canisters. I wanted to get the particularly disruptive changes all out at once, though

1 Like

This is really good to hear! This will move us closer to more intuitively integrating with other front end frameworks such an Angular. Look forward to seeing the change, please keep us posted.

Those are awesome changes!. Going forward, do you think it will be possible to have autocomplete in motoko plugin for VS Code?

That’s a Motoko language feature, and I don’t think there’s much of a roadmap for the motoko plugin right now. I’ll bring it up with the team, at least!

1 Like

Ready to test! Check out dfx version 0.7.6, which you can install with

DFX_VERSION="0.7.6" sh -ci "$(curl -fsSL"

The easiest way to see how the types work now is with the new dfx new templated project. If all goes well, we will promote this version to stable soon

1 Like

Tried the new version 0.7.6 on MacBook pro Big Sur 11.4
dfx --version
dfx 0.7.6

dfx new test_me
dfx start
I get that error

Stopping icx-proxy...
dyld: Library not loaded: /nix/store/2v68by9vfqg4i555apwxxkxpwa67x6m1-openssl-1.1.1i/lib/libssl.1.1.dylib
  Referenced from: /Users/my_macos/.cache/dfinity/versions/0.7.6/icx-proxy
  Reason: image not found

The error wasn’t there before at 0.7.2
There’s a solution on stackoverflow dyld: Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
But haven’t tried it, not sure if it’s needed tho

1 Like

Oh, if there’s a hard coded nix reference, that would explain why it worked for our machines and pipeline but would fail elsewhere

Yep. We’ve got a PR open for it. Thanks for trying it out, and we’ll get to work on a 0.7.7 release

@coin_master can you try again? the 0.7.7 candidate is released

That works like a charm :slight_smile: Thanks,

1 Like