Simplify the readme. I don't think there needs to be that much information. The main things we want to explain to a user when using this module is:

• It reads each module name and it's version
  • If it is not versioned, an error is thrown (to avoid bad practice)
  • only deno.land urls are supported
  • Otherwise, it would would in any format the code is in (no changes needed by the user toher than versioning if needed), for example:
    • The URL in single or double quotes, semi-colons at end of the line, comments, exporting or importing.
• The update process will only re-write the version of the module in the users deps.ts

Summary

What: If you run deno lint, we will most likely have a whole bunch of errors. This issue to fix these errors by correctly formatting code, and abiding by Deno's standards

Why: It would be good to make sure the code follows either: Deno's best practices, coding standards, or general best practices. It's a Deno project so it makes sense to utilise their tools on making the code Deno-like

Acceptance Criteria

• deno lint is added to the master.yml CI, as a new block (similar to how we use deno fmt --check on some repositories)
• deno lint produces no errors

Resources

Deno Lint Documentation

Summary

What:

Integrate https://github.com/ebebbington/depcheck into dmm to provide a feature for checking unused dependencies

I think this feature would best fit under the check command.

Why:

I built depcheck as a port of NPM's version because it is actually really useful, and there's no easy way to check if you aren't using a certain dependency - and removing those can 'clean up' the codebase. Myself and Eric think it would be a better idea for dmm to incorporate this feature and im happy to archive my own repo

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write documentation
• Write unit tests
• Write integration tests
• Develop feature

Example Pseudo Code (for implementation)

$ dmm check
Dependency `http` in `./src/deps.ts` is unused. Consider removing this.

see impl form depcheck repo

Summary

What: Use Deno's cdn (https://cdn.deno.land/std/meta/versions.json) to get the latest std version instead

Why: More reliable than a file. One good example was today, when deno team forgot to update the file we use for the latest version, meaning dmm did updated <module> from 0.66.0 to 0.65.0

Acceptance Criteria

• Use cdn to get latest version instead

Example Pseudo Code (for implementation)

Related file: src/services/deno_service.ts Related method: _getLatestStdRelease`

Summary

What:

Inside getModuleDataFromDepsFile, check if the module name already resides inside modules. If so, continue, else carry on adding it.

Why:

Theres no need to run all the logic to collate the module data, if we already have it. Take for example, pulling stuff from std/http but different files (so 2 separate import statements), we have all the information needed after the first one, so this will reduce the total time taken to run the commands

Pseudo-code For Implementation

// src/services/module_services.ts

// Whilst looping through the dep content data inside `constructModulesDataFromDeps`:
...
    ...
    // easier to do when we have the github or deno.land url
    const alreadyAggregated = modules.find(module => {
        return module.gitHubUrl === githubUrl
    }) !== undefined
    if (alreadyAggregated) {
        return
    }
...

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Summary

When checking, and if a dependency can be updated, add a link to stdout to the release notes.

Should be relatively easy as the logic that gets the latest version uses a URL to their releases, for example: github.com/.../releases/latest - it should just be a matter of saving this url and adding it to the module object as a releaseURL property or something. Then log these out.

It might require some formatting to make the output look clean, for example:

Now:

...
fs can be updated from [version] to [version]
...

Adding formatting:

...

- fs
  Can be updated from [version] to [version]
  [release link]
...

Acceptance Criteria

• Add a release link to each module that should be displayed on check
• Update/fix tests
• Update README (if needed)

Pseudo-code for Implementation

// src/interfaces/module.ts

// Add: latestReleaseLink?: string|boolean

// src/services/module_service.ts

// Inside the for loop for `constructModulesDataFromDeps`:
const latestReleaseLink = importedVersion !== latestRelease ?
    gitHubUrl + "/releases/latest"
    :
    false

...

modules.push({
    ...
    latestReleaseLink
})

// src/commands/check.ts
modules.forEach((module) => {
    if (module.importedVersion !== module.latestRelease) {
      depsCanBeUpdated = true;
      listOfModuleNamesToBeUpdated.push(module.name);
      console.info(
        colours.yellow(
+         "- " + module.name + "\n" +
+        "    Can be updated from " + module.importedVersion + " to " + module.latestRelease + "\n" +
+        "    " + module.latestReleaseLink
        ),
      );
    }
  });

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Please support unpkg.com as CDN

import Table from "https://unpkg.com/[email protected]/dist/index.mjs"

To get the latest version of a package, simply remove the @Version from the url and parse the location header.

❯ curl https://unpkg.com/table-layout/dist/index.mjs
Found. Redirecting to /[email protected]/dist/index.mjs⏎        

Summary

What:

Have a downgrade subcommand that downgrades modules to a specific version or the previous version.

Why:

If someone updates their deps and realizes later that their deps don't work with their project and they want to downgrade their deps, they need to do it manually. dmm downgrade would do it for them.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write documentation
• Write unit tests
• Write integration tests

Wants to update all those modules even though they're already up to date.

Summary

the docs say to run with --allow-read='deps.ts' but i get the following permission error. if i run with --allow-read='.', like in the previous version, its fine.

$ deno run --allow-net='cdn.deno.land,api.deno.land,x.nest.land,raw.githubusercontent.com,github.com,api.github.com' --allow-read='deps.ts' --allow-write='deps.ts' https://deno.land/x/dmm/mod.ts update
[INFO] Reading deps.ts to gather your dependencies...
error: Uncaught (in promise) PermissionDenied: Requires read access to ".", run again with the --allow-read flag
const usersWorkingDir: string = Deno.realPathSync(".");
^
at Object.opSync (deno:core/01_core.js:149:12)
at Object.realPathSync (deno:runtime/js/30_fs.js:137:17)
at Function.constructModulesDataFromDeps (https://deno.land/x/[email protected]/src/services/module_service.ts:61:42)
at UpdateSubcommand.handle (https://deno.land/x/[email protected]/src/commands/update.ts:17:41)
at UpdateSubcommand.run (https://deno.land/x/[email protected]/src/subcommand.ts:82:16)
at Dmm.#runSubcommand (https://deno.land/x/[email protected]/src/main_command.ts:228:32)
at Dmm.run (https://deno.land/x/[email protected]/src/main_command.ts:65:30)
at CLI.run (https://deno.land/x/[email protected]/src/cli.ts:86:29)
at https://deno.land/x/[email protected]/mod.ts:20:5

Summary

Versions with a release candidate or non-traditional versioning is not correctly replaced.

Steps To Reproduce The Bug

1. Create a deps.ts with the following:

export { createBot } from 'https://deno.land/x/[email protected]/mod.ts';

2. Run dmm on the file.
3. Observed: 13.0.0-rc34 becomes 13.0.0-rc36-rc34

Expected Behavior

The entire version string should be found, not just the 13.0.0.

Suggested Solution(s)

Correction to the version matching detection.

Screenshots

N/A

Additional Context

[INFO] Reading deps.ts to gather your dependencies...
[INFO] Checking if your modules can be updated...
[INFO] discordeno was updated from 13.0.0 to 13.0.0-rc36

Summary

What: I realise that there aren't any unit tests... whilst everything is pretty much covered by the existing tests, it would be beneficial to have unit tests.

Why: We expand upon knowing the project works as expected

Acceptance Criteria

• Unit tests are added for all src code
• Cmd to run tests is added to the master workflow (if not already included)

Summary

What: Wonder if it's worth adding a bumper (bumper script used by Drash) to Dmm? (lol)

Why: Keeps dependencies up to date

Acceptance Criteria

• Add bumper script

Example Pseudo Code (for implementation)

Could have the bumper just run from mod.ts directory

Summary

What:

From the CLI, allow a user to specify a path to a dependency file. This should (and could) be used in conjunction with the following commands: update, check.

Along with this, allow the user to pass in a --dir flag. If the user passes this in, then dmm should read every file within that directory (shouldn't check if the filenames have deps in it).

Why:

Some people of Deno (including ourselves) are taking the approach to having more than 1 deps file, eg test_deps.ts in a different folder - this would support that

Acceptance Criteria

• A --file=some_file.ts flag can be passed, and only that file will be checked
• A --dir=some_dir flag can be passed, and each file within that dir will be checked
  • If there is another dir inside that dir, then the logic should call itself to check that nested directory
• Above flags cannot be used together
• Update README
• Update src/options/help.ts
• Tests covering this
• src/options/help.ts updated to reflect changes

Example Pseudo Code (for implementation)

• Default to deps.tswhen that option was passed

• If it was, ensure the file exists

  • If it doesnt, send error

• Read. the file as normal

• Example usage would be: dmm. update --file=tests/deps.ts

function updateDir(dirName) {
  const everything[] = openAllFilesDirectory(dirName);
  for (const file of everything) {
    if (file.isNotTypeScript() == true) {
      continue;
    }
    if (file.isDirectory() == true) {
      updateDir(file);
      continue;
    }
    functionToUpdateFile(file);
  }
}

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

The tests for the update command are all commented out as I haven't yet had the time to think about how we would go about testing it, as I assume we would need to test that a deps.ts has been modified to upgrade versions, but we'd want this file to be defaulted to it's original state for the other update tests

• Finish the tests inside /tests/update_test.ts

Example on how a .travis.yml would look:

language: minimal

os:
  - osx
  - linux

before_install:
  - export PATH=$HOME/.deno/bin:$PATH

install:
  - curl -fsSL https://deno.land/x/install/install.sh | sh -s v1.0.5

script:
  - deno test --allow-run --allow-read

But implement using Github workflow

Summary

Note: {version} is the latest std release. I do not mean to use "{version} literally

What: Update documentation, option files, tests and test deps to remove the v from all instances where std@v{version} is being used

Why: std@v{version} is no longer supported due to the new registery. Std imports must be imported like std@{version}

Acceptance Criteria

• All std imports or strings or output should display std@{version} or {version} instead of std@v{version} and v{version}

Describe the bug
When trying the installation route, it fails on

Check https://deno.land/x/[email protected]/mod.ts
error: Invalid executable name: [email protected]

To Reproduce
Using the deno install --allow-net --allow-read --allow-write https://deno.land/x/[email protected]/mod.ts command.

Expected behavior
Successful installtion.

Screenshots

Desktop (please complete the following information):

• OS: Manjaro Linux 20.1
• Deno: 1.3.1

Please let me know if you need additional information.

Summary

What: Right now, dmm only supports imports from Deno.land. It would be good to support usage from nest.land too, as not doing so puts a limitation on users using dmm. Although Nest have their own CLI, I still think it would be good should people wish to use Nest imports and dmm

Why: Lifts a limitation for users, to not restrict imports to only one registry (that Deno wanted to avoid eg npm)

Acceptance Criteria

• Add x.nest.land to the supported registries. Atm this is just if the line contains Deno.land, but might be good to hold a const for supported registries and add this to documentation

Example Pseudo Code (for implementation)

Class ModuleService {
    protected supported_registries = [
        deno.land
        X.nest.land
    ]

    ...

    const isSupported = this.supported_registries.filter(r => line.indexOf(r) !== -1).length > 0

Describe the bug

The CI showed that the tests were failing due to dependencies having been upgraded. For example, Drash was upgraded to v1.1.0, but the tests were expecting a different version and not the latest version.

To Reproduce

deno test --allow-net --allow-env --allow-run

Also, see: https://github.com/drashland/dmm/runs/886656005?check_suite_focus=true

Expected behavior

Tests should pass.

• Update readme to mention this module will only read lines with versions

• Add a warning message for a dependency if its imported using the master branch

  • Would probably be present on check and update

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Summary

What:

Currently, our regex matches v1.2.3, 1.2.3, 1.2.3.4.5.6 (and so on), but semver tags could be v1.2.3-rc1. We don't support that and we should.

Why:

We don't know what module versions will be released -- whether they're following semver or not, but if they are following semver, then it's possible that a module's version could be v1.2.3-alpha; and we don't support that yet.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Match semver tags (see semver.org for possible semver tags)
• Write unit tests

Summary

What:

Use services repo for CLI, logging, and bumping versions for DRY code

Why:

DRY the codebase

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Documentation (https://github.com/drashland/website/issues/209)
  • Include updated help message and changes to info subcommand
• Tests

https://nest.land/

Summary

What:

Alongside supporting deno.land and x.nest.land, add support for https://raw.githubusercontent.

Why:

So dmm can update dependencies imported from GitHub.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write documentation (https://github.com/drashland/website/issues/225)
• Write unit tests
• Develop the feature

Taking on this issue? Read this before you get started.

If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.

Please read the Contributing Guidelines before starting this issue.

Describe the bug

deno run --allow-net --allow-read --allow-write https://deno.land/x/[email protected]/mod.ts check
Gathering facts...
Reading deps.ts to gather your dependencies...
error: Uncaught TypeError: Cannot read property 'split' of undefined
        ? (dep.split("@" + importedVersion + "/")[1]).split("/")[0]
                                                      ^
    at Function.constructModulesDataFromDeps (https://deno.land/x/[email protected]/src/services/module_service.ts:94:55)
    at async check (https://deno.land/x/[email protected]/src/commands/check.ts:14:19)
    at async run (https://deno.land/x/[email protected]/mod.ts:13:5)
    at async https://deno.land/x/[email protected]/mod.ts:56:1

To Reproduce

1. Open root project
2. Launc dmm check

Desktop (please complete the following information):

• OS: Windows 10 and WSL2 Ubuntu

Additional context
Test repo link: https://github.com/kKen94/deno-test

Checklist

• Add dmm --version functionality (can be tested by doing deno run mod.ts --version)

• Update helpMessage inside src/options/help.ts to include this new functionality

• Update README to include this

• Update DEV.md to have that version string updated on a new release

• Add tests at tests/options/... to assert it works correctly

Pseudo-code for Implementation

// src/options/version.ts
const version = "current dmm version"
export default const versionMessage = `dmm ${version}`

// mod.ts
import versionMessage from "..."
const wantsVersion = args.filter(arg => arg.indexOf("--version") > 0).length === 1
if wantsVersion
    console.info(versionMessage)
    Deno.exit()

Summary

What:

ServiceLogger is now ConsoleLogger in [email protected]. There should be no side effects after making these changes.

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write unit tests
• Write integration tests
• {add more checkboxes required by this issue as needed}

Summary

What: Test and add documentation on how to install/run dmm by restricting access for permissions, eg `--allow-read='deps.ts'

Why: Dmm only needs to read and write to deps.ts, and it would be good for users to know any other files will not be affected

Acceptance Criteria

• Docs are updated on how to restrict the access

Summary

What:

Look at the current code, and improve it, making it scale for new features and possibly making it scale for using GitLab

Why:

I feel adding new features can be made easier to do if the code is improved, as well as general code improvements

Acceptance Criteria

Below is a list of tasks that must be completed before this issue can be closed.

• Write unit tests
• Write integration tests

Improve the tests by asserting the correct messages are sent to stdout, for example:

const p = await Deno.run({
     ...
    stdout: "piped"
})
const status = await p.status()
const output = await p.output() // also closes eg p.close()
const outputString = new TextDecoder('utf-8').decode(output)
assertEquals(outputString, '.... \n ....')

Why? Because then we truly know everything is working

Summary

What: Convert JSDoc blocks (though we use a mix of JSDoc and Deno's standard), to TSDoc blocks in Typescript files

Why: We primarily use TypeScript so it makes sense to use TSDoc. Types are already documented in the method/property anyways.

Acceptance Criteria

• All doc blocks converts to TSDoc

Example Pseudo Code (for implementation)

* @param string filename
*        The filename to do something with

* @param filename - The filename to do something with

Resources

TSDoc is very similar, there is really only a few minor changes to make to each doc block

https://github.com/microsoft/tsdoc

Updates

• feat: Added support for nest.land modules (#77)
• chore: Doc, output and code improvements (#74)
• chore: Add documentation of restricting permissions (#53)