nmscd / coordinate-conversion

Library with conversion functions for NMS coordinates

Coordinate Conversion

Library with conversion functions for NMS coordinates

Installation

NPM:

npm i @nmscd/coordinate-conversion

From CDN with <script> tag:

<script type="text/javascript" src="https://nmscd.com/Coordinate-Conversion/bundle.js"></script>

Converters

• PortalCode
  • Inputs (only one is required)
    • code - 03894AC8D91F
    • hexArray - ['0', '3', '8', '9', '4', 'A', 'C', '8', 'D', '9', '1', 'F']
    • numberArray - [0, 3, 8, 9, 4, 10, 12, 8, 13, 9, 1, 15]
  • Methods
    • toGalacticCoordinates
    • toVoxel
• GalacticCoordinate
  • Inputs (only one is required)
    • code - 0C55:00D5:0922:0234 or 0C5500D509220234
    • groups - ['0C55', '00D5', '0922', '0234']
  • Methods
    • toGlyph
    • toVoxel
• VoxelCoordinate
  • VoxelCoordinates
  • Methods
    • toGlyph
    • toGalacticCoordinates

Conversion result

The conversions will return an object to indicate whether the conversion was successful or not.

const galacticConversionResult = PortalCode({ code: '023456123456' }).toGalacticCoordinates();
console.log(galacticConversionResult); // { isSuccess: true, value: '0C55:00D5:0922:0234', errorMessage: ''

const voxelConversionResult = GalacticCoordinate({ code: '0C55:00D5:0922:0234' }).toGlyph();
console.log(voxelConversionResult); // { isSuccess: true, value: '023456123456', errorMessage: ''

// Example of error in conversion
const galacticConversionResult = PortalCode({ code: 'tester' }).toGalacticCoordinates();
console.log(galacticConversionResult); /*
{
  isSuccess: false,
  value: '',
  errorMessage: 'Character is an unexpected value (t), expected values 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, a, b, c, d, e, f, A, B, C, D, E, F'
}
*/

Types

Voxel Coordinates

import type { VoxelCoordinates } from '@nmscd/coordinate-conversion';

type VoxelCoordinates = {
  voxelX: number;
  voxelY: number;
  voxelZ: number;
  solarSystemIndex: number;
  planetIndex: number;
};

Code coverage

View our current code coverage report

coordinate-conversion's Issues

Don't trigger release when no code was changed

@Khaoz-Topsy picking up from #3, we can discuss the issue here.

The problem

There shouldn't be a version bump and subsequent new npm release when no code was changed, e.g. when the readme was updated or when tests were edited.

The solution

We can use the paths or paths-ignore option in our CI/CD workflows to specify whether something should run, based on which files were edited. Syntax for this can be found in the GitHub Docs

The question is whether we use paths or paths-ignore.

As stated in the docs, we can also negate a pattern. I think with this, using paths requires the least amount of thinking: If a file is listed, it will trigger the workflow. As you suggested, we can use src/**/* to glob all relevant ts files. We can also add !src/**/*.spec.* to exclude the test files.

An alternative solution to this would be to put tests into their own tests folder, and just exclude that (or put it outside of src entirely)

GH Pages CI fails

@Khaoz-Topsy seems like the GH Pages CI pipeline fails because it cannot find the github-actions module. You added the vitest reporter exactly as the docs say, so I have no idea why this happens. Can we just disable the GH Actions reporter for now?

Require version bump workflow

Currently, the version bump workflow is not set as required when merging to main because it doesn't execute when no code is altered.

This also means that the PR isn't blocked when this job fails.

Instead, the job should always trigger, and the edited paths should be checked in the job-level if statement.

This could be done with another job that checks whether the files have changed and then sets a boolean as its output.

See: https://stackoverflow.com/questions/70708306/github-actions-run-step-job-in-a-workflow-if-changes-happen-in-specific-folde

Filter action: https://github.com/dorny/paths-filter