Skip to content
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

use vscode files API instead #288

Open
0mkara opened this issue Mar 21, 2023 · 1 comment
Open

use vscode files API instead #288

0mkara opened this issue Mar 21, 2023 · 1 comment
Assignees
Labels
backlog Issues and PRs those are pushed back enhancement New feature or request

Comments

@0mkara
Copy link
Member

0mkara commented Mar 21, 2023

we have been using native fs in multiple places like -

Screenshot 2023-03-22 at 1 53 56 AM

We should be using vscode file system API instead whereever possible.

@0mkara 0mkara added the enhancement New feature or request label Mar 21, 2023
@Krish-bhardwaj
Copy link
Collaborator

To migrate from node fs module to vscode File System API we will have to change following things
Documentation

  1. Structure change
    • initially we are using the normal file system used in os for eg . Path type : C:\Users\...\hardhat\contracts\greeter.sol would change to vscode.URI type file://Users\...\hardhat\contracts\greeter.sol so initiall we woild want to change path type to vscode.URI
    • All the function that are available in fs module are not exactly available in vscode File System API thus we would have to rewrite the function where ever there is a use of fs module in ethcode , but as per my observation we have all the required api for our current need
    • We can observe changes in code base by following examples
      • if we read a file using normal fs module it would work like this
                      const getDeployedInputs: any = (context: vscode.ExtensionContext) => {
                        try {
                          const contract = context.workspaceState.get(
                            'contract'
                          ) as CompiledJSONOutput
                          const fullPath = getDeployedFullPath(contract)
                          const inputs = fs.readFileSync(fullPath).toString()
                          return JSON.parse(inputs)
                        } catch (e) {
                          return undefined
                        }
                      }
      • if we read a file using vscode File System API it would work like this
        const getFunctionInputFile: any = async (
        context: ExtensionContext,
        name: string
      ): Promise<object | undefined> => {
        try {
          const contracts = context.workspaceState.get('contracts') as Record<string, CompiledJSONOutput>
          if (contracts === undefined || Object.keys(contracts).length === 0) return
      
          const contract = Object.values(contracts).find(contract => contract.name === name)
          if (contract != null) {
            const link = getFunctionInputFullPath(contract)
            const linkchnage = link.replace(/\\/g, '/')
            const parsedUrl = new URL(linkchnage)
            const fileUrl: vscode.Uri = vscode.Uri.parse(`file://${parsedUrl.pathname}`)
            const contents: Uint8Array = await vscode.workspace.fs.readFile(fileUrl)
            const decoder = new TextDecoder()
            const jsonString = decoder.decode(contents)
            const json = JSON.parse(jsonString)
            return json
          }
        } catch (error) {
          console.log(error)
        }
      } 
  2. Output change
    • We are not sure that how much role does fs module play in terms of performance and how better is it going to be if we use vscode File System API
    • Right now ethcode extension is working fine with this fs module
    • If we plan to migrate or standardise vscode File System API for file related operation in ethcode we should make sure that further whatever development are should be made in vscode File System API and gradually migrate previous code base to the same

@0mkara 0mkara added the backlog Issues and PRs those are pushed back label Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Issues and PRs those are pushed back enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants