-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: export ContractClient
et al. in contract
; rename SorobanRpc
to rpc
#962
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
absolutely Herculean 👏 coupla requests ⬇️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I defer to @Shaptic, just one question from me.
9b55dce
to
0832590
Compare
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat is debug access?Uses debug, reflection and dynamic code execution features. Removing the use of debug will reduce the risk of any reflection and dynamic code execution. What is filesystem access?Accesses the file system, and could potentially read sensitive data. If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead. Take a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with
|
This includes some fixes and updates to eslint configuration to make it work as expected - Extended `airbnb-typescript/base` to get it to stop yelling at me about importing files without file extension. Saw this recommended as the fix on StackOverflow [[1]]. And it makes sense to me that if we are extending Airbnb's lint rules and using TypeScript, we probably want their TypeScript-specific lint rules, too. - Added the `eslint-plugin-jsdoc` plugin because the old `valid-jsdoc` rule we were using has been deprecated [[2]], and this plugin is the new way. Previously we had `valid-jsdoc: 1` (with some extra customization), and my guess is that extending `plugin:jsdoc/recommended` (plus some customization) is roughly equivalent. - Researched [[3]] whether JSDoc `@param`-style docs or TSDoc-style `/** inline param docs */` work better. TSDoc work better. So disabled `jsdoc/require-param`. [1]: https://stackoverflow.com/a/67610259/249801 [2]: https://eslint.org/docs/latest/rules/valid-jsdoc [3]: stellar#962 (comment)
0832590
to
31e6123
Compare
This includes some fixes and updates to eslint configuration to make it work as expected - Extended `airbnb-typescript/base` to get it to stop yelling at me about importing files without file extension. Saw this recommended as the fix on StackOverflow [[1]]. And it makes sense to me that if we are extending Airbnb's lint rules and using TypeScript, we probably want their TypeScript-specific lint rules, too. - Added the `eslint-plugin-jsdoc` plugin because the old `valid-jsdoc` rule we were using has been deprecated [[2]], and this plugin is the new way. Previously we had `valid-jsdoc: 1` (with some extra customization), and my guess is that extending `plugin:jsdoc/recommended` (plus some customization) is roughly equivalent. - Researched [[3]] whether JSDoc `@param`-style docs or TSDoc-style `/** inline param docs */` work better. TSDoc work better. So disabled `jsdoc/require-param`. [1]: https://stackoverflow.com/a/67610259/249801 [2]: https://eslint.org/docs/latest/rules/valid-jsdoc [3]: stellar#962 (comment)
31e6123
to
c01532d
Compare
This includes some fixes and updates to eslint configuration to make it work as expected - Extended `airbnb-typescript/base` to get it to stop yelling at me about importing files without file extension. Saw this recommended as the fix on StackOverflow [[1]]. And it makes sense to me that if we are extending Airbnb's lint rules and using TypeScript, we probably want their TypeScript-specific lint rules, too. - Added the `eslint-plugin-jsdoc` plugin because the old `valid-jsdoc` rule we were using has been deprecated [[2]], and this plugin is the new way. Previously we had `valid-jsdoc: 1` (with some extra customization), and my guess is that extending `plugin:jsdoc/recommended` (plus some customization) is roughly equivalent. - Researched [[3]] whether JSDoc `@param`-style docs or TSDoc-style `/** inline param docs */` work better. TSDoc work better. So disabled `jsdoc/require-param`. [1]: https://stackoverflow.com/a/67610259/249801 [2]: https://eslint.org/docs/latest/rules/valid-jsdoc [3]: stellar#962 (comment)
c01532d
to
3e90f84
Compare
Didn't realize just how unhappy ESLint is with basically all the code in this repo 🤔 I saw that I also fixed some config issues that I introduced earlier, so you can lint the whole repo again. And find that we have:
¯\_(ツ)_/¯ Good enough for now, I guess?? |
This includes some fixes and updates to eslint configuration to make it work as expected - Extended `airbnb-typescript/base` to get it to stop yelling at me about importing files without file extension. Saw this recommended as the fix on StackOverflow [[1]]. And it makes sense to me that if we are extending Airbnb's lint rules and using TypeScript, we probably want their TypeScript-specific lint rules, too. - Added the `eslint-plugin-jsdoc` plugin because the old `valid-jsdoc` rule we were using has been deprecated [[2]], and this plugin is the new way. Previously we had `valid-jsdoc: 1` (with some extra customization), and my guess is that extending `plugin:jsdoc/recommended` (plus some customization) is roughly equivalent. - Researched [[3]] whether JSDoc `@param`-style docs or TSDoc-style `/** inline param docs */` work better. TSDoc work better. So disabled `jsdoc/require-param`. - Remove mostly-duplicate `src/soroban/.eslintrc.js`, which had only one setting different from `src/.eslintrc.js` Note that `src/contract_client` is now perhaps the only directory of code to pass our ESLint settings 🤔 [1]: https://stackoverflow.com/a/67610259/249801 [2]: https://eslint.org/docs/latest/rules/valid-jsdoc [3]: stellar#962 (comment)
3e90f84
to
2ee6126
Compare
654af31
to
bc8df30
Compare
ContractClient
; rename SorobanRpc
to Rpc
bc8df30
to
798b4b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small notes but otherwise this is 🔥 🔥 🔥 great work! 👏
Uses the in-progress branch at stellar/js-stellar-sdk#962, which will be merged and released as 12rc3 soon. This PR can be updated to use the release at that point. Note that using the new `import { Client } from '@stellar/stellar-sdk/ContractClient` entrypoint requires getting rid of the "build the TS Bindings for both Common JS and ES Modules" behavior we had before. I think this is fine. From [TypeScript's `moduleResolution` documentation](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-libraries): > When compiling a library, you don’t know where the output code will > run, but you’d like it to run in as many places as possible. Using > `"module": "nodenext"` (along with the implied `"moduleResolution": > "nodenext"`) is the best bet for maximizing the compatibility of the > output JavaScript’s module specifiers, since it will force you to comply > with Node.js’s stricter rules for import module resolution. We also don't really need these generated NPM modules to be more flexible than stellar-sdk itself, and it doesn't do the build-to-cjs-and-esm thing.
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
ContractClient
; rename SorobanRpc
to Rpc
ContractClient
et al. in contracts
; rename SorobanRpc
to rpc
This includes some fixes and updates to eslint configuration to make it work as expected - Extended `airbnb-typescript/base` to get it to stop yelling at me about importing files without file extension. Saw this recommended as the fix on StackOverflow [[1]]. And it makes sense to me that if we are extending Airbnb's lint rules and using TypeScript, we probably want their TypeScript-specific lint rules, too. - Added the `eslint-plugin-jsdoc` plugin because the old `valid-jsdoc` rule we were using has been deprecated [[2]], and this plugin is the new way. Previously we had `valid-jsdoc: 1` (with some extra customization), and my guess is that extending `plugin:jsdoc/recommended` (plus some customization) is roughly equivalent. - Researched [[3]] whether JSDoc `@param`-style docs or TSDoc-style `/** inline param docs */` work better. TSDoc work better. So disabled `jsdoc/require-param`. - Remove mostly-duplicate `src/soroban/.eslintrc.js`, which had only one setting different from `src/.eslintrc.js` Note that `src/contract_client` is now perhaps the only directory of code to pass our ESLint settings 🤔 [1]: https://stackoverflow.com/a/67610259/249801 [2]: https://eslint.org/docs/latest/rules/valid-jsdoc [3]: stellar#962 (comment)
7862b46
to
1bcb161
Compare
2936139
to
49ae5bf
Compare
ContractClient
et al. in contracts
; rename SorobanRpc
to rpc
ContractClient
et al. in contract
; rename SorobanRpc
to rpc
This includes some fixes and updates to eslint configuration to make it work as expected - Extended `airbnb-typescript/base` to get it to stop yelling at me about importing files without file extension. Saw this recommended as the fix on StackOverflow [[1]]. And it makes sense to me that if we are extending Airbnb's lint rules and using TypeScript, we probably want their TypeScript-specific lint rules, too. - Added the `eslint-plugin-jsdoc` plugin because the old `valid-jsdoc` rule we were using has been deprecated [[2]], and this plugin is the new way. Previously we had `valid-jsdoc: 1` (with some extra customization), and my guess is that extending `plugin:jsdoc/recommended` (plus some customization) is roughly equivalent. - Researched [[3]] whether JSDoc `@param`-style docs or TSDoc-style `/** inline param docs */` work better. TSDoc work better. So disabled `jsdoc/require-param`. - Remove mostly-duplicate `src/soroban/.eslintrc.js`, which had only one setting different from `src/.eslintrc.js` Note that `src/contract_client` is now perhaps the only directory of code to pass our ESLint settings 🤔 [1]: https://stackoverflow.com/a/67610259/249801 [2]: https://eslint.org/docs/latest/rules/valid-jsdoc [3]: stellar#962 (comment)
e9fb8dc
to
8bf93ea
Compare
8bf93ea
to
5eafd56
Compare
- `SorobanRpc` now also exported as `rpc` - New main export `contract` This allows us to import it the usual way, instead of needing to do things like import { ContractClient } from "stellar-sdk/lib/contract_client" which doesn't work in the browser (because `lib`) - `ContractSpec` now available at `contract.Spec` - Also includes other supporting classes, functions, and types: - `contract.AssembledTransaction` - `contract.ClientOptions` - etc - These are also available at matching entrypoints, if your node and TypeScript configuration support the `exports` declaration: import { Client, ClientOptions, AssembledTransaction, } from 'stellar-sdk/contract' This also attempts to document exported modules. The JSDoc-style comments in `src/index.ts` don't actually show up when you import these things. We can figure this out later. Docs here https://jsdoc.app/howto-es2015-modules. In the meantime, these are still useful notes that we can use later. Co-authored-by: George <Shaptic@users.noreply.github.com>
78e13e0
to
7883dc3
Compare
Uses the in-progress branch at stellar/js-stellar-sdk#962, which will be merged and released as 12rc3 soon. This PR can be updated to use the release at that point. Note that using the new `import { Client } from '@stellar/stellar-sdk/contract` entrypoint requires getting rid of the "build the TS Bindings for both Common JS and ES Modules" behavior we had before. I think this is fine. From [TypeScript's `moduleResolution` documentation](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-libraries): > When compiling a library, you don’t know where the output code will > run, but you’d like it to run in as many places as possible. Using > `"module": "nodenext"` (along with the implied `"moduleResolution": > "nodenext"`) is the best bet for maximizing the compatibility of the > output JavaScript’s module specifiers, since it will force you to comply > with Node.js’s stricter rules for import module resolution. We also don't really need these generated NPM modules to be more flexible than stellar-sdk itself, and it doesn't do the build-to-cjs-and-esm thing.
Uses the in-progress branch at stellar/js-stellar-sdk#962, which will be merged and released as 12rc3 soon. This PR can be updated to use the release at that point. Note that using the new `import { Client } from '@stellar/stellar-sdk/contract` entrypoint requires getting rid of the "build the TS Bindings for both Common JS and ES Modules" behavior we had before. I think this is fine. From [TypeScript's `moduleResolution` documentation](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-libraries): > When compiling a library, you don’t know where the output code will > run, but you’d like it to run in as many places as possible. Using > `"module": "nodenext"` (along with the implied `"moduleResolution": > "nodenext"`) is the best bet for maximizing the compatibility of the > output JavaScript’s module specifiers, since it will force you to comply > with Node.js’s stricter rules for import module resolution. We also don't really need these generated NPM modules to be more flexible than stellar-sdk itself, and it doesn't do the build-to-cjs-and-esm thing.
Uses the in-progress branch at stellar/js-stellar-sdk#962, which will be merged and released as 12rc3 soon. This PR can be updated to use the release at that point. Note that using the new `import { Client } from '@stellar/stellar-sdk/contract` entrypoint requires getting rid of the "build the TS Bindings for both Common JS and ES Modules" behavior we had before. I think this is fine. From [TypeScript's `moduleResolution` documentation](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-libraries): > When compiling a library, you don’t know where the output code will > run, but you’d like it to run in as many places as possible. Using > `"module": "nodenext"` (along with the implied `"moduleResolution": > "nodenext"`) is the best bet for maximizing the compatibility of the > output JavaScript’s module specifiers, since it will force you to comply > with Node.js’s stricter rules for import module resolution. We also don't really need these generated NPM modules to be more flexible than stellar-sdk itself, and it doesn't do the build-to-cjs-and-esm thing.
Breaking Changes
ContractClient
functionality previously added in v11.3.0 was exported in a non-standard way. You can now import it as any other stellar-sdk module.Note that this top-level
contract
export is a container for ContractClient and related functionality. The ContractClient class is now available atcontract.Client
, as shown. Further note that there is a capitalizedContract
export as well, which comes from stellar-base. You can remember which is which because capital-CContract
is a class, whereas lowercase-ccontract
is a container/module with a bunch of classes, functions, and types.Additionally, this is available from the
/contract
entrypoint, if your version of Node and TypeScript support theexports
declaration. Finally, some of its exports have been renamed.The
ContractSpec
class is now nested under thecontract
module, and has been renamed toSpec
.Alternatively, you can import this from the
contract
entrypoint, if your version of Node and TypeScript support theexports
declaration.Previously,
AssembledTransaction.signAndSend()
would return aSentTransaction
even if the transaction never finalized. That is, if it successfully sent the transaction to the network, but the transaction was stillstatus: 'PENDING'
, then it wouldconsole.error
an error message, but return the indeterminate transaction anyhow.It now throws a
SentTransaction.Errors.TransactionStillPending
error with that error message instead.Deprecated
SorobanRpc
module is now also exported asrpc
. You can import it with either name for now, butSorobanRpc
will be removed in a future release.You can also now import it at the
/rpc
entrypoint, if your version of Node and TypeScript support theexports
declaration.Other
contract
directory (previously thecontract_client
directory). While this turned out to be a bit premature (given that much other code in this repo doesn't pass our eslint rules), it's still nice cleanup. That's why you'll see.eslintrc.js
changes and related code updates. Some notes on all this:.eslintrc.js
,src/.eslintrc.js
, andsrc/soroban/.eslintrc.js
. The second two were very similar. I made them identical and removed the more deeply nested one.src
, but were only using Airbnb's non-TypeScript recommended settings. They recommend using both, for TypeScript projects. That's what I've done.eslint-plugin-jsdoc
. I've done that, and extended their recommended rules. I've overridden some rules. For example, I researched and found that documenting function params with@param
doesn't actually show up in your in-editor typeahead/mouseover. So I turned off the rule that requires these. We should prefer TSDoc for params instead. I've added these throughout.export * as blah from 'whatever'
lines insrc/index.ts
. These don't actually show up when you import these objects. We will need to research this more when we do a larger module reorganization later. For now, they're useful notes.