cleaned up contributing guide

Author: dcrescim

CONTRIBUTING_GUIDE.md

@@ -19,23 +19,21 @@ npm run test:clean
 
 The following repo has 4 main directories:
 
-- `scikitjs-browser`: Contains build/test commands for the browser version of scikitjs
-- `scikitjs-node`: Contains build/test commands for the node version of scikitjs
+- `src`: Contains the majority of the code for implementing scikit-learn Estimators, and helper functions
 - `docs`: Contains a docusaurus site which builds the `scikitjs.org` site. Has blogs/tutorials/apis documentation
-- `shared`: Contains all the code that is shared between browser and node versions of this library.
 
-For anyone creating Estimators or writing scikit-learn functions, you'll likely be spending your time in the `shared/lib` directory. It contains a directory-like structure that matches the scikit-learn directory structure. So there is a `cluster` directory, and a `model_selection` directory, etc.
+For anyone creating Estimators or writing scikit-learn functions, you'll likely be spending your time in the `src` directory. It contains a directory-like structure that matches the scikit-learn directory structure. So there is a `cluster` directory, and a `model_selection` directory, etc.
 
-The following files are available in the `shared/lib` directory:
+The following files are available in the `src` directory:
 
 - `index`: Entry file which exports all features.
 - `utils`: A collection of reusable utility functions.
 - `types`: A file for declaring Typescript types.
 
 Some important scripts in the package.json file are:
 
-- `test:clean` : Build both browser and node versions, and runs all tests against them
-- `build` : Builds both the browser and node versions of this library
+- `test:clean` : Runs tests against node.js version of src code
+- `build` : Builds all bundles (esm, cjs, script src)
 - `build:docs`: Builds a local version of the site `scikitjs.org`
 
 ## Code Style
@@ -96,9 +94,9 @@ Type names are typically nouns or noun phrases. For example, Request, ImmutableL
 
 #### Method names
 
-Method names are written in lowerCamelCase e.g `addNum`. Names for private methods must start with a dollar sign e.g `$startAddition`, and should be declared as private.
+Method names are written in lowerCamelCase e.g `addNum`.
 
-Method names are typically verbs or verb phrases. For example, `sendMessage` or `$stopProcess`. Getter and setter methods for properties are never required, but if they are used they should be named `getFoo` (or optionally `isFoo` or `hasFoo` for booleans), or `setFoo(value)` for setters.
+Method names are typically verbs or verb phrases. For example, `sendMessage` or `stopProcess`. Getter and setter methods for properties are never required, but if they are used they should be named `getFoo` (or optionally `isFoo` or `hasFoo` for booleans), or `setFoo(value)` for setters.
 
 #### Constant names
 
@@ -134,9 +132,9 @@ JSDOCs attached to the class or functions are automatically converted into the A
 
 ## **Writing tests**
 
-We strongly encourage contributors to write tests for their code. Like many packages, [danfojs](https://danfo.jsdata.org/) uses [mocha](https://mochajs.org/).
+We strongly encourage contributors to write tests for their code. Like many packages, [scikitjs](https://scikitjs.org) uses [jest](https://jestjs.io/).
 
-All tests should go into the file suffixed by `.test.ts` and place in the corresponding module. The test files contain some current examples of tests (e.g. `kmeans.test.ts`), and we suggest looking to these for inspiration.
+All tests should go into the file suffixed by `.test.ts` and be placed next to the corresponding src code. The test files contain some current examples of tests (e.g. `kmeans.test.ts`), and we suggest looking to these for inspiration.
 
 Below is the general framework to write a test for each module.
 
@@ -147,7 +145,7 @@ import { addSeries } from './addSeries' //compiled build
 describe('Name of the class|module', function () {
   it('name of the methods| expected result', function () {
     //write your test code here
-    //use assert.{property} to test your code
+    //use expect(thing).toEqual to test your code
   })
 })
 ```
@@ -163,9 +161,8 @@ describe("Name of the class|module", function(){
  describe("method name 1", function(){
 
    it("expected result",function(){
-
         //write your test code here
-        //use assert.{proprty} to test your code
+    //use expect(thing).toEqual to test your code
     })
   })
 
@@ -174,7 +171,7 @@ describe("Name of the class|module", function(){
    it("expected result",function(){
 
         //write your test code here
-        //use assert.{proprty} to test your code
+      //use expect(thing).toEqual to test your code
     })
   })
   .......
@@ -183,22 +180,6 @@ describe("Name of the class|module", function(){
 
 ### **Running the test case**
 
-To run the test for the module/file you created/edited,
-
-**1\)** Change `describe` to `describe.only` at the top of the test file
-
-**2\)** If you are in the shared directory, you can run the test case against the node library by typing
-
-```bash
-npm run test:node
-```
-
-You can also test your code against the browser version by running
-
-```bash
-npm run test:browser
-```
-
-Note that running tests against the browser is usually a bit slower because we build the browser bundle. I usually test against node for quick iterations, and then at the end test against the browser.
+To run the test for the module/file you created/edited, just run jest over that single file
 
-Learn more about mocha [here](https://mochajs.org/)
+**1\)** Simply run `npx jest ./path/to/file.test.ts`